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Preface 


The  purpose  of  this  research  was  to  investigate  the 
manner  in  which  design  and  construction  project  managers 
evaluate  change  requests  to  the  design  and  construction  of 
facility  projects.  The  facility  occupant  or  other  agency 
impacted  by  the  facility  project  is  a  major  source  of 
requested  changes.  Regulations  and  management  plans 
provide  some  guidance  to  project  managers  on  evaluation  of 
these  requests.  The  project  manager  is  aware  that  user 
change  requests  increases  costs  and  delays  project 
completion  dates.  However,  the  project  manager  must  weigh 
this  consideration  with  serving  the  customer  by  building 
quality  facilities  to  enhance  the  customers'  productivity. 
This  research  interviewed  expert  project  managers  to 
conclude  with  important  issues  the  project  manager  should 
understand  about  this  evaluation  process. 

In  conducting  this  research,  I  am  deeply  indebted  to, 
first  and  foremost,  my  thesis  advisor.  Major  Larry 
Lawrence.  His  enthusiastic  support,  timely  feedback,  and 
probing  questions  greatly  assisted  in  the  formulation  and 
assembly  of  a  coherent  study.  I  also  want  to  thank  my 
thesis  reader.  Major  Larry  Emmelhainz,  for  overseeing  the 
progress  and  providing  valuable  information.  Finally,  I 
wish  to  thank  the  personnel  at  the  Air  Force  Regional  Civil 
Engineer  (AFRCE)  Central  Region  and  Ballistic  Missile 
support,  and  in  the  Engineering  Branch  at  Headquarters 
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strategic  Air  Command  for  their  hospitality  and  for 
allowing 
the  data 


me  to  interview  their  personnel,  so  I  could  gather 
to  develop  the  conclusions  of  this  research. 
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v  ' 

This  resdarch  examines  the  evaluation  process  of  Air 
Force  design  and  construction  project  managers  on  user 
requested  changes  to  facility  construction  projects. 

Project  managers  who  incorporate  user  requested  changes 
probably  enhance  the  facility  quality,  but  also  adversely 
affect  the  project  execution  (on  time  and  within  available 
resources)  and  the  Air  Force  image  before  Congress.  The 
researcher  interviewed  27  experienced  project  managers  in  3 
different  organizations  on  their  decision-making  processes 
to  balance  the  tradeoffs  between  cost,  performance, 
enhancing  user  productivity,  and  schedule. 

This  research  employs  a  "reason  analysis*^ methodology . 

I '  ' 

Therefore,  this  research  develops  rather  than  tests  a 
specific  hypothesis.  Frequency  counts  and  open-ended 
questions  help  show  the  most  important  criteria  in  the 
decision  making  process.  Relating  responses  of  various 
questions  helped  the  researcher  gain  insights  into  the 
change  request  process  in  general .  .  f  _ - 

The  research  developed  an  information  guide  for  use  by 
Air  Force  project  managers  when  evaluating  user  change 
requests.  This  guide  helps  to  educate  project  managers 
from  the  experiences  of  other  project  managers. 


XI 


Evaluating  user  change  requests  includes  the  following 
three  major  areas:  their  early  detection,  the 
administrative  process,  and  the  evaluation  factors.  Early 
detection  of  user  change  requests  are  derived  from  factors 
that  caused  revisions  to  the  original  change  request.  The 
administrative  process  includes  those  procedural  items 
judged  most  important  by  the  interviewees.  The  research 
divided  the  evaluation  factors  into  two  classifications. 

The  first  group  addresses  why  project  managers  act  as  they 
do  in  evaluating  the  requests.  The  second  group  identifies 
the  factor  associated  with  either  the  facility  quality  or 
project  execution.  Also,  the  research  scores  these 
evaluation  factors  according  to  their  importance  and 
difficulty  of  use,  as  perceived  by  the  project  managers. 
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EVALUATING  USER  CHANGE  REQUESTS 


IN  FACILITY  CONSTRUCTION 


I .  Introduction 


Chapter  Overview 

This  chapter  provides  background  information  with  this 
research's  general  issue:  impacts  of  user  requested 
changes  to  Military  Construction  (MILCON)  projects.  In 
addition,  this  chapter  states  the  research's  problem 
statement,  research  objectives,  and  the  research's  scope 
and  limitations. 

Background 

A  MILCON  project  "...  starts  when  a  requirement  for 
a  facility  is  identified  and  ends  with  a  completed  facility 
that  hopefully  satisfied  the  requirement"  (33:1).  Congress 
annually  approves  projects  over  $200  thousand  in  the  MILCON 
program  by  the  Military  Construction  Authorization  and 
Military  Construction  Appropriation  Acts  (15:10).  The 
MILCON  process  consists  of  the  following  five  phases:  (1) 
requirements  development,  (2)  validation,  (3)  programming, 
(4)  design,  and  (5)  construction  (37:1).  The  user  may 
request  changes  during  any  phase  of  the  MILCON  process. 

AFR  89-1,  Design  and  Construction  Management,  outlines 
the  policies,  goals,  and  responsibilities  for  the  design 
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and  construction  of  Air  Force  facilities.  AFR  89-1  applies 
to  MILCON  projects,  as  well  as  other  types  of  construction 
programs . 

The  goal  of  the  design  and  construction  phases  of  all 
programs  .  .  is  to  satisfy  the  user's  needs  with  quality 
construction”  (11:4).  AFR  89-1  defines  the  user  as  "The 
lowest  level  commander  exercising  operational  control  over 
the  function  for  which  the  project  is  programmed"  (11:30). 
AFR  89-1  also  states  that: 

The  primary  objective  of  design  and  construction 
management  is  to  acquire  quality  facilities  on  time 
and  within  available  resources.  The  facilities  must 
be  reliable  and  maintainable,  meet  prescribed 
environmental  standards,  and  enhance  user  productivity 
and  livability.  (11:3) 

The  Air  Force  Regional  Civil  Engineer  (AFRCE)  assists 
with  managing  the  design  and  construction  phases  of 
designated  projects  of  the  Air  Force  MILCON  Program  (10:1). 
There  are  four  AFRCEs  (Eastern  Region,  Western  Region, 
Central  Region,  and  the  AFRCE  for  Ballistic  Missile  Support 
(BMS)).  The  continental  United  States  (CONUS)  is  divided 
into  three  geographical  regions,  with  one  AFRCE  assigned  to 
a  region.  The  BMS  AFRCE  is  responsible  for  the 
construction  supporting  the  MX  (Peacekeeper)  missile 
system.  In  addition,  the  MAJCOMs  may  be  delegated  AFRCE 
responsibilities  (10:2).  Some  of  the  AFRCE 
responsibilities  include  the  following: 
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1.  Issue  directives  to  assure  cost  control. 

2.  Furnish  the  design/construction  agent  with  Air 
Force  criteria  for  design  and  construction. 

3 .  Review  and  approve  design  time  schedules  and 
costs. 

4.  Obtain  coordination  from  all  appropriate  agencies 
on  the  functional  adequacy  of  the  construction  plans 
(10:3)  . 

The  "project  book"  contains  detailed  user  requirements 
for  each  MILCON  project,  unless  the  design  manager  waives 
the  requirement  to  prepare  a  project  book  (13:8).  In 
addition  to  the  user  requirements,  the  project  book 
contains  MAJCOM  policies,  functional  requirements,  and  cost 
information  (11:29).  The  MAJCOM  is  responsible  for 
preparing  the  project  book  during  the  programming  phase  of 
the  MILCON  process.  The  information  in  the  project  book 
serves  as  the  basis  to  prepare  the  construction  plans  and 
specifications . 

The  purpose  of  the  project  book  is  to  document  all 
data,  criteria  and  functional  requirements  for  the  facility 
design  and  construction.  The  user  plays  a  key  role  in 
preparing  the  project  book.  If  the  user  provides  a  quality 
description  of  their  functional  requirements  for  the 
project  book,  the  user  involvement  during  the  design  and 
construction  phases  of  the  MILCON  process  should  be  minimal 
(33:11) . 
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Changes  and  Their  Impact  on  the  MILCON  Process 

Stollbrink,  in  his  thesis,  writes  about  the  impact  of 
changes  during  the  last  three  phases  (programming,  design, 
and  construction)  in  MILCON  projects.  He  states  that: 


Changes  during  the  programming  phase  usually  do 
not  pose  major  problems  as  they  often  involve  changing 
the  scope  of  the  project.  However,  this  could  delay 
project  approval  and  if  the  scope  change  is  large  and 
occurs  after  the  project  has  been  approved  it  could 
delay  or  kill  the  project. 

Changes  during  the  design  phase  can  cause  more 
significant  problems,  especially  if  they  require  an 
increase  in  project  scope  and/or  a  major  redesign 
effort.  Changes  during  the  construction  phase  are 
typically  very  expensive  and  should  be  avoided  at  all 
costs. 

Changes  during  the  design  and/or  construction 
phases  can  also  cause  costly  time  delays.  Changes 
during  the  design  phase  can  also  result  in  possible 
loss  of  the  project  due  to  increased  cost.  (33:1-2) 


Stollbrink  identifies  one  possible  reason  why  Civil 
Engineers  must  evaluate  change  requests  in  the  design  and 
construction  phases  of  a  project.  He  states  that  the 
project  book  information  may  not  be  current  for  several 
reasons.  The  first  reason  is  that  the  user  may  not  have 
passed  all  known  requirements  to  Civil  Engineering. 
Stollbrink  surveyed  users  of  MILCON  projects  completed  in 
1984  and  1985.  He  reported  that  most  users  felt  project 
books  adequately  described  their  requirements,  although 
26.7  percent  felt  that  project  books  described  their 
functional  requirements  to  a  low  degree  (33:31).  The 
second  reason  for  the  project  book  containing  insufficient 
or  out-dated  information  is  that  a  substantial  percentage 
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(38.1  percent)  of  the  users  were  not  aware  of  the  purpose 
of  the  project  book  (33:27). 

Major  General  Wright  (retired,  previous  Director  of 
Engineering  and  Services  in  the  United  States  Air  Force) 
identifies  another  possible  reason  why  Civil  Engineering 
must  become  involved  with  evaluating  change  requests  in 
design  and  construction.  Major  General  Wright  stated  that 
the  current  Air  Force  construction  process  produces  poor 
construction  blueprints  and  specifications  (38:16).  He 
said  that  design  packages  are  "...  filled  with  errors, 
omissions,  or  other  problems"  which  result  in  " .  .  . 
excessive  changes  and  claims  that  lead  to  missed  completion 
dates,  inferior  products,  and  .  .  .  cost  overruns.  People 
end  up  frustrated"  (38:16). 

Rosmond  states,  in  his  thesis,  that  customer  change 
requests  are  difficult  to  predict.  The  request  may  be  in 
response  to  unpredicted  changes  in  mission  requirements,  or 
a  result  of  inadequate  planning.  The  change  request  may 
represent  a  real  facility  need  or  be  a  compromise  for 
requirements  no  longer  needed  (31:28). 

Fortunately,  Air  Force  contracts  have  "changes" 
clauses  which  gives  the  Air  Force  flexibility  to  purchase 
"changed"  work  without  repeating  the  contract  advertisement 
process.  These  clauses  save  a  substantial  administrative 
effort  because  the  work  change  can  be  negotiated,  under 
certain  circumstances,  with  the  original  contractor 
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(31:14).  Change  orders  provide  the  Air  Force  flexibility 
to  accomplish  mission  objectives. 

However,  government  agencies  have  been  accused  of 
excessive  use  of  change  orders.  Criticism  is  focused  on, 
among  other  things,  not  screening  non-essential  changes 
(31:28).  The  Defense  Audit  Service  and  the  Air  Force  Audit 
Agency  criticized  both  the  Department  of  Defense  (DOD)  and 
the  Air  Force,  in  audits  conducted  in  1982  and  1987,  for 
not  screening  user  change  requests  (31:28;  14:9).  The 
results  of  the  1987  audit  are  explained  below. 

The  Air  Force  Audit  Agency,  as  part  of  a  1987  DOD-wide 
audit,  studied  whether  the  Air  Force  was  exercising 
adequate  control  over  construction  changes.  The  Agency 
reviewed  146  change  requests  (worth  $12.3  million)  and 
disclosed  that  89  changes  (worth  $9.3  million)  could  have 
been  voided.  They  also  determined  that  changes  delayed 
construction  up  to  three  months  (14:6-7).  The  Agency 
recommended  that  procedural  improvements  were  needed  to 
(among  other  items) :  "a.  Identify  essential  changes 

before  construction  begins,  b.  Limit  user-requested 
changes  to  mission  essential  changes"  (14: Cover  letter). 

In  addition,  the  Engineering  and  Services  Directorate 
at  Headquarters  Air  Force  analyzed  the  reasons  for  non¬ 
execution  of  Air  Force  MILCON  projects  for  fiscal  years 
(FY)  1986,  1987,  and  1988.  Non-execution  in  MILCON 
projects  occurs  when  the  government  can  not  award  the 
project  construction  contract  in  the  same  year  Congress 
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appropriates  and  authorizes  funds  for  the  project.  For 
FY86,  48  out  of  82  non-executed  MILCON  projects  can  be 
classified  as  "user-related/caused"  (18 : Summary) .  For 
FY87,  26  out  of  56  non-executed  MILCON  projects  can  be 
classified  as  "user-related/caused"  (16: Summary) .  For 
FY88,  30  out  of  56  non-executed  MILCON  projects  can  be 
classified  as  "user-related/caused"  (17 : Summary) . 

User  related  causes  are  a  major  factor  for  the  non¬ 
execution  of  MILCON  projects.  Below  is  a  discussion  of  the 
Air  Force  policy  and  guidance  on  evaluating  user  requested 
changes . 

Policy  on  Evaluating  User  Requested  Changes 

From  1978  till  1988,  the  1978  version  of  AFR  89-1 
provided  policy  and  guidance  to  Civil  Engineering  on  how  to 
evaluate  change  requests  in  design  and  construction.  If 
the  1982  and  1987  audits  show  the  Air  Force  was  not 
effectively  screening  user  change  requests,  then  this 
regulation's  guidance  was  either  incorrect,  insufficient, 
or  not  being  followed.  The  1978  version  of  AFR  89-1 
addressed  the  following  two  areas  of  evaluating  change 
requests:  coordinating  with  various  agencies  and 

determining  the  impacts  of  the  change.  The  following  is  a 
discussion  of  these  areas. 

First,  the  1978  version  of  AFR  89-1  addressed  the 
coordination  process  by  stating  that  the  MAJCOM  has  the 
responsibility  for  internal  communications  during  the 
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design.  The  review  process  includes  coordination  with  the 
following  agencies:  communications,  safety, 
bioenvironmental  engineer,  security  police,  fire 
department,  and  the  user  (13:7-5).  After  construction 
contract  award,  the  MAJCOM  is  responsible  for  coordination 
(among  other  duties)  of  construction  (13:12-2). 

Second,  to  address  the  impacts  of  change,  the  1978 
version  of  AFR  89-1  stated  that  ’’Efforts  by  the  using 
agencies  to  make  functional  changes  after  award  will 
generally  be  resisted  unless  they  are  mandatory  mission 
oriented  requirements”  (13:12-4).  A  checklist  of  items 
that  assist  the  civil  engineer  in  determining  the  mission 
impact  of  a  change  request  include  the  following: 

1.  Does  the  change  fit  within  scope  of  project  and 
construction  contract? 

2.  How  does  change  affect  contractor's  schedule? 

3.  What  is  status  of  project  at  time  of  change? 

4.  How  is  his  work  force  affected? 

5.  Will  subcontractors  be  involved  (13:12-4)? 

The  Air  Staff  published  a  revision  AFR  89-1  on  1 

November  1988  to  provide  new  and  updated  guidance  to  design 
and  construction  project  managers  on  evaluating  change 
requests.  This  version  of  AFR  89-1  ”...  gives  increased 
flexibility  to  the  MAJCOMs  for  design  and  construction  of 
their  programs.  .  .  .”  (11:24).  It  also  addresses 
evaluating  user  changes  in  both  the  design  and  construction 
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management  sections.  The  following  is  a  discussion  of  that 
evaluation  process. 

The  latest  version  of  AFR  89-1  addresses  user 
requested  changes  for  projects  more  than  35  percent 
complete  in  design  by  stating  that  the  host  and  requiring 
MAJCOM  "Validates  and  approves  user-proposed  comments  after 
the  35  percent  design  approval  only  when  the  change  is 
necessary  to  meet  the  mission"  (11:14).  It  also  identifies 
implementation  procedures  for  three  types  of  changes 
(mandatory  changes,  optional  changes,  and  user  requested 
changes)  that  could  occur  after  construction  starts. 
Mandatory  changes  are  necessary  to  satisfy  safety  and 
minimum  technical  adequacy  requirements.  Optional  changes 
are  not  mandatory  for  the  facility  to  function  (11:9) .  To 
implement  user  requested  changes: 

The  requiring  MAJCOM  validates  and  approves  user 
change  requests,  to  the  degree  of  funds  availability, 
up  to  the  PA  [Programmed  Amount].  The  changes  must  be 
necessary  to  meet  the  mission.  MAJCOMs  may  delegate 
some  or  all  user  change  request  authority  to  base 
level.  (11:9) 

A  29  January  1986  letter  titled  "Management  of  the 
Military  Construction  Program,"  signed  by  the  Air  Force 
Vice  Chief  of  Staff,  provides  one  possible  basis  for  the 
new  version  of  AFR  89-1.  This  letter  states  that  "Air 
Force  policy  on  user  changes  is  only  those  changes 
absolutely  necessary  to  meet  the  mission  should  be  made 
after  the  concept  stage  (35  percent  design)"  (29:1).  In 
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the  same  paragraph  of  the  letter  is  "The  user  will  approve 
the  design  before  construction  starts"  (29:1).  The  last 
paragraph  of  this  letter  addresses  the  impacts  of 
implementing  user  requested  changes  by  stating  "Failure  to 
meet  OSD  execution  goals  has  a  direct  impact  on  our  ability 
to  defend  our  requests  for  MILCON  funds  through  the  PBD 
cycles  and  on  the  Hill"  (29:1). 

Problem  Statement 

Incorporating  user  requested  changes  enhances  the 
quality  of  facility  design  and  construction;  however,  the 
problem  is  that  it  adversely  affects  the  Air  Force 
execution  (on  time  and  within  resources)  of  the  project. 
Quality  facilities  are  reliable  and  maintainable,  meet 
prescribed  environmental  standards,  and  enhance  user 
productivity  and  livability  (11:3).  To  obtain  quality 
facilities  and  at  the  same  time  keep  the  project  on  time 
and  within  cost,  requires  addressing  the  following  research 
objectives  and  questions. 

Research  Objectives 

The  objectives  of  this  research  are  the  following: 

1.  To  identify  factors  of  effective  decision-making 
actions  on  user  change  requests. 

2.  To  arrange  these  factors  in  a  format  that  Civil 
Engineering  project  managers  can  use. 

3.  To  recommend  ways  to  implement  these  factors. 
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Research  Questions 

To  investigate  factors  of  effective  decision-making 
techniques  in  evaluating  user  change  requests,  the 
following  investigative  questions  must  be  answered; 

1.  What  factors  should  be  used  to  evaluate  change 
requests? 

2.  How  should  the  evaluation  factors  vary  in 
different  stages  of  the  design  and  construction  phases,  if 
at  all? 

3.  How  should  the  factors  be  weighed  to  evaluate 
change  requests? 

4.  What  formal  procedures  should  the  project  manager 
follow  to  process  the  change  request? 

5.  What  types  of  organizations  should  the  user  change 
request  be  coordinated  with? 

6.  Do  any  existing  decision  support  systems  address 
how  to  evaluate  requested  changes? 

Justification  for  Research 

Air  Force  Civil  Engineering  does  not  build  quality 
facilities  because  inaccuracies  exist  in  project  books. 
Incomplete  or  unknown  requirements  may  cause  inaccuracies 
in  the  project  books.  To  correct  these  inaccuracies 
requires  the  user  submitting  a  change  request  to  the 
project  manager  during  either  design  or  construction. 
However,  if  the  design  is  more  than  35  percent  complete  and 
the  users  change  the  facility  design  criteria,  for  whatever 
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reason,  the  end  result  is  the  delayed  completion  of  the  Air 
Force  facility.  These  delays  result  in  the  following: 

1.  Affect  Air  Force  readiness  because  initial 
operational  dates  slip  due  to  uncompleted  facilities. 

2.  Require  diversion  of  scarce  resources  from  other 
projects  to  pay  for  additional  design  and  construction 
costs . 

3.  Impacts  the  Air  Force's  ability  to  defend  requests 
for  future  MILCON  funds. 

This  research  should  help  project  managers  evaluate 
user  requested  changes  to  the  facility  design  and 
construction  to  acquire  quality  facilities,  consequently 
ensuring  the  project  is  executed  on  time  and  within 
resources.  The  design  and  construction  project  managers 
can  then  determine  the  tradeoffs  between  cost,  performance, 
and  schedule  for  optional  changes  requested  by  the  user. 

Scope  and  Limitations 

This  research  addresses  MILCON  construction  projects 
managed  by  the  AFRCEs  or  other  agencies  (e.g.  MAJCOMs)  that 
act  as  AFRCEs.  Here-in-after,  this  research  will  refer  to 
the  individual  managing  the  MILCON  project  in  either  design 
or  construction  as  the  "project  manager"  or  "design  and 
construction  project  manager." 

Several  facets  limit  the  research.  First,  only  CONUS 
construction  projects  that  were  completed  within  the  last 
year  or  are  currently  under  design  or  construction  are 
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considered.  Other  types  of  construction,  such  as 
maintenance  and  repair  projects,  are  excluded  to  limit  the 
research  to  a  manageable  effort.  In  addition,  this 
research  does  not  consider  non-conventional  contracting 
methods  for  construction,  such  as  "design-build 
contracting. " 

This  research  only  addresses  change  requests  submitted 
from  users  or  other  organizations  outside  of  Civil 
Engineering  involved  with  either  the  design  or 
construction.  These  change  requests  may  result  from 
unforeseen  or  previously  unidentified  requirements,  or  from 
the  need  to  correct  design  deficiencies  to  satisfy  project 
requirements,  Here-in-after,  both  these  items  will  be 
referred  to  as  "user  changes,"  "user  change  requests”  or 
"user  requested  changes.” 

Chapter  Summary 

Incorporating  user  requested  changes  enhances  the 
quality  of  facility  design  and  construction  but  adversely 
affects  the  Air  Force  execution  (on  time  and  within 
resources)  of  the  project.  The  research  objectives  and 
questions  are  based  on  this  problem.  Understanding  the 
process  of  effective  decision-making  in  evaluating  user 
requested  changes  should  assist  the  project  manager  in 
identifying  and  balancing  the  relevant  factors. 

Incorporating  user  requested  changes  in  design  (beyond 
the  conceptual  design  phase)  delays  project  completion  and 


13 


increases  costs,  while  at  the  same  time  affect  the  Air 
Force's  ability  to  acquire  future  MILCON  funds.  Project 
managers,  who  implement  these  requested  changes,  need  to 
balance  building  quality  facilities  for  the  user  while 
executing  the  project  within  money  and  time  limitations. 

The  project  book  identifies  user  requirements  for  the 
MILCON  project.  The  Civil  Engineering  project  manager 
should  work  closely  with  the  user  in  preparing  design 
criteria  for  the  construction.  However,  for  one  reason  or 
another,  the  project  book  may  not  contain  all  user 
requirements.  To  correct  these  deficiencies  will  require 
change  requests  to  the  design  or  construction. 

AFR  89-1  provides  important  guidance  to  Civil 
Engineering  on  how  to  evaluate  user  change  requests  in 
design  and  construction.  AFR  89-1  has  been  recently 
revised,  to  allow  MAJCOMs  more  flexibility  to  initiate 
their  own  procedures  on  evaluating  user  change  requests. 

The  key  factor  that  AFR  89-1  identifies  in  the  evaluation 
of  change  requests  is  "are  they  mission  essential?"  The 
Air  Force  Audit  Agency  highlighted  this  point  in  their  1987 
review  of  the  Air  Force  MILCON  process. 

Remaining  Chapters  of  Thesis 

The  remaining  chapters  discuss  the  process  to  achieve 
the  research  objectives.  Chapter  II  (Literature  Review) 
provides  a  thorough  background  on  the  relevant  literature 
of  evaluating  user  requested  changes.  Chapter  III 
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(Methodology)  discusses  the  methods  used  for  data 
collection  and  analysis.  Chapter  IV  (Results)  presents  the 
summary  tables  of  the  interviewee  responses.  Chapter  V 
(Analysis  and  Discussion)  explains  the  research  results  by 
analyzing  the  summary  tables.  Chapter  VI  (Summary  and 
Recommendations)  addresses  the  research  objectives  and 
concludes  with  recommendations  for  further  research. 


II. 


Literature  Review 


Chapter  Overview 

User  change  requests  represent  new  or  different 
criteria  to  a  facility  design  baseline.  This  chapter 
discusses  the  Air  Force  design  process,  and  explains  when 
the  facility  concept  is  finalized  and  when  detailed  design 
begins.  It  is  also  important  to  understand  current 
practices  on  evaluating  changes  to  design  requirements  and 
to  the  construction.  This  chapter  discusses  these 
practices  both  inside  and  outside  the  Air  Force. 

There  are  many  publications  that  describe  impacts  of 
changes  to  design  and  construction.  However,  the 
researcher  could  not  find  much  literature  on  decision¬ 
making  to  balance  facility  construction  to  enhance  user 
productivity  versus  executing  the  project  on  time  and 
within  budget  (which  is  the  objective  of  this  research,  see 
Chapter  I) .  The  researcher  believes  managers  in  the  weapon 
system  acquisition  process  face  similar  tradeoff  decisions. 
Thus,  this  literature  review  also  includes  information 
about  user  changes  in  the  weapon  system  acquisition 
process,  where  additional  information  is  available  on 
managing  user  change  requests. 

What  is  a  Baseline? 

Zylstra  writes  about  a  baseline  when  describing 
government  contract  compliance  and  product  acceptance.  A 
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baseline  is  a  snapshot  of  an  engineering  design  that  can  be 
described  by  reviews  of  the  product  documentation  (40:66). 
This  baseline  concept  also  applies  to  Air  Force 
construction,  as  the  product  could  be  considered  a 
facility.  In  essence,  construction  blueprints  and 
specifications  represent  snapshots  of  the  facility 
development.  These  blueprints  and  specifications  change 
after  each  engineering  design  review.  This  research  did 
not  find  any  publications  that  address  the  construction 
blueprints  and  specifications  as  a  baseline  in  Air  Force 
Civil  Engineering  design  reviews.  However,  the  baseline 
concept  is  important  because  it  represents  an  agreement 
between  Civil  Engineering  and  the  customer  on  the 
characteristics  of  the  facility. 

Identifying  the  Baseline 

In  Air  Force  Civil  Engineering,  the  project  book  best 
represents  an  initial  snapshot  of  the  facility.  AFR  89-1, 
Design  and  Construction  Management,  states  the  project  book 
contains  user  requirements  to  support  design  of  the 
facility  (11:29).  The  project  book  increases  the 
probability  of  getting  the  best  possible  facility  at 
minimum  cost  and  with  least  amount  of  change  (33:10-11). 

A  project  book  is  normally  required  for  each  MILCON 
project  (11:8).  Inputs  from  the  users  and  other  third 
organizations  involved  with  the  facility  are  the  basis  for 
the  design  criteria,  data,  functional  requirements,  and 


17 


cost  information.  The  project  book  details  design 
information  for  MILCON  projects  (11:29). 

The  US  Army  Construction  Engineering  Research 
Laboratory  (CERL)  Report,  Preparing  and  Communicating 
Habitability  Design  Information,  describes  the  importance 
of  the  user  communicating  his  requirements  to  the  designer. 
The  report  states: 

Habitability  is  a  concern  for  how  functional  a 
facility  is  to  a  user.  Functional  habitability  must 
be  integrated  into  the  plans  and  specifications  since 
the  functional  quality  of  a  facility  is  affected  by 
virtually  all  of  its  components.  This  requires 
intense  user  involvement.  (5:11) 

Habitability  information  should  generally  state  how 
the  various  user  functions  will  relate  to  each  other.  To 
help  ensure  that  the  design  requirements  are  complete,  the 
designers  should  arrange  meetings  with  the  users  and 
conduct  site  visits  (5:20-22). 

The  user  design  information  falls  into  the  following 
three  different  categories:  (1)  requirements,  (2) 
standards,  and  (3)  guidance.  It  is  important  for  the 
designer  to  classify  user  inputs  in  the  appropriate 
category.  Requirements  refer  to  what  is  needed  or  design 
goals.  Requirements  are  specific  for  each  project,  and  are 
most  useful  to  the  designer.  Designers  use  standards  (the 
second  category)  to  satisfy  these  requirements.  If 
standards  do  not  exist,  then  users  can  recommend  design 
information  in  the  form  of  guidance  (5:14). 
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Brauer  recommends  the  designer  also  needs  to  be  aware 
of  prescriptive  and  descriptive  forms  of  information.  In 
describing  user  inputs,  users  often  provide  descriptive 
information,  referring  to  how  things  can  be  done. 
Descriptive  information  contains  examples  of  useful  and 
innovative  ideas.  However,  it  is  up  to  the  designer  to 
determine  if  user  inputs  can  be  translated  into  a 
prescriptive  form,  or  how  things  ought  to  be  (5:14-15). 

Finalizing  the  Baseline 

Audits  are  formal  comparisons  of  the  engineering 
design  and  documentation  with  the  applicable  baseline  and 
user  requirements.  Audits  are  conducted  and  the  baseline 
is  reestablished  as  the  products  pass  through  the 
engineering  design  process  and  into  production  (40:66). 

This  concept  also  applies  in  Air  Force  construction. 
Technical  and  user  reviews  of  construction  blueprints  and 
specifications  are  conducted  when  the  design  is  30  percent 
complete  ”.  .  .so  that  changes  will  not  be  required  after 
award”  (19:23).  Upon  completion  of  this  review,  the  design 
is  considered  35  percent  complete.  Here,  the  baseline  is 
reestablished . 

User  requirements  should  not  change  after  the  design 
is  35  percent  complete.  A  29  Jan  86  letter  signed  by  the 
Vice  Chief  of  Staff  of  the  Air  Force  emphasized  ”...  that 
the  final  concept  design  [35  percent  design]  is  the  last 
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chance  for  the  user  to  identify  requirements,  except  for 
necessary  mission  changes"  (29:1). 

The  design  is  35  percent  complete  when  "...  the 
designer  has  established  the  basic  features,  materials, 
systems,  and  related  costs  necessary  to  meet  the  functional 
requirements  of  a  facility"  (11:30).  The  35  percent  design 
contains  preliminary  drawings,  an  outline  of  the 
specifications,  basis  of  design,  and  a  preliminary  cost 
estimate.  Also  at  the  35  percent  design  stage, 
consolidated  user  requirements  and  construction  cost 
estimates  are  forwarded  to  the  Secretary  of  Defense  to 
become  a  basis  of  the  budget  estimate  submittal  (12:4-1). 
Congress  approves  each  MILCON  project  based  on  what  defense 
requirements  are  satisfied  by  funding  of  that  project.  The 
final  design,  to  proceed  to  100  percent  complete,  will 
start  after  Congressional  approval  (19:23). 

The  "Changes"  Clause 

A  MILCON  project  typically  has  an  Architect  and 
Engineer  (AE)  contractor  to  prepare  the  construction 
blueprints  and  specifications  based  on  Air  Force  criteria. 
In  almost  all  cases,  construction  contractors  would  build 
the  MILCON  project.  This  section  addresses  changes  to  both 
the  design  and  construction  phases  of  contracting. 

Rosmond  writes  that  the  "changes"  clause  allows  the 
government  to  purchase  additional  work  under  an  existing 
contract  provided  the  change  is  within  the  general  scope  of 
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work  of  the  contract.  This  clause  saves  the  government  a 
great  deal  of  work.  The  government  can  negotiate  with  the 
original  contractor,  rather  than  competitively  bid  the 
work.  Although  the  contractor  is  in  a  strong  bargaining 
position,  knowing  that  no  price  competition  exists  (31:14). 

Rosmond  reported  that  the  purpose  of  the  "changes” 
clause  is  not  for  the  contractor  to  recover  from  his  own 
errors  of  judgement  or  calculations  (by  securing  additional 
money  to  pay  for  a  loss  that  occurred  on  another  part  of 
the  job) .  He  concludes  that  "There  is  no  question  that  the 
'Changes'  clause  has  been  used  for  the  purpose  of  improving 
the  contractor's  position"  (31:16). 

Managing  Change  Recfuests 

The  purpose  of  controlling  changes  is  to  prevent 
unnecessary  ones  and  expedite  approval  and  implementation 
of  worthwhile  ones  (27:70). 

Chadwick,  while  discussing  the  impact  of  design  on  the 
quality  of  facility  construction,  states  that  change 
control  assures  that  the  project  is  within  schedule  and 
budget.  Failure  to  maintain  change  control  leads  to  a 
great  deal  of  trouble  for  the  owner,  and  change  control  is 
often  neglected  until  it  is  to  late  (6:73). 

Chadwick  writes  that  changes  should  be  subject  to 
formal  control  early  in  the  design  process.  The  key  to  the 
change  control  is  organization,  for  without  it,  changes  may 
accumulate  into  the  thousands.  Chadwick  identifies  two 
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test  questions  to  answer  to  determine  the  need  for  the 
change.  They  are:  "1.  Will  the  change  be  cost-effective 
and  not  delay  work  elsewhere?  2.  Will  the  related  system 
operate  safely  .  .  .  without  this  change?"  (6:77) . 

In  an  article  on  construction  cost  control,  Maevis 
raises  two  questions,  similar  to  Chadwick,  to  answer  before 
a  reaching  decision  on  a  change  request.  The  questions  are 
the  following:  "(1)  What  is  the  estimated  cost  of  the 
change;  and  (2)  What  effect  will  it  have  upon  the 
completion  date  of  the  project?"  (26:439).  Maevis 
researched  the  United  States  Postal  Service  policy  on 
change  orders  in  construction.  He  found  that: 

...  a  regional  and  headquarters  instruction  which 
requires  that  once  the  30%  design  mark  has  been 
passed,  there  may  be  no  changes  to  the  design  unless 
an  involved  review  and  approval  process  is  followed. 

It  involves  the  Assistant  Postmaster  General  for  Real 
Estate  and  Buildings  and  may  go  to  two  Senior 
Assistant  Postmasters.  General,  [sic]  This 
discourages  casual  or  'nice  to  have*  changes.  Again, 
it  works.  (26:439) 

DeFeis  wrote  about  the  prevention  of  change  orders  in 
construction.  He  says  that  they  may  never  be  eliminated, 
especially  on  large  projects.  However,  he  says  that  a 
proven  project  management  system  should  be  implemented 
which  includes,  among  other  items,  contract  administration, 
including  change  order  procedures  (9:17). 

DeFeis  writes,  similar  to  Chadwick,  that  "Procedures 
which  process  change  order  requests  expediently  and 
efficiently  should  be  in  place  before  ground  is  broken" 
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(9;18).  A  flow  chart  helps  to  visualize  procedures  to 
evaluate  change  requests.  The  flow  chart  should  show 
change  order  processing  paths,  approvals,  parties  providing 
input,  and  a  distribution  list  of  copies  of  the  change 
request  (9:18). 

Configuration  Management 

This  section  describes  one  possible  method  to  manage 
changes.  The  researcher  included  material  on  the  weapon 
system  acquisition  process  because  of  the  limited  material 
on  evaluating  change  requests  in  construction. 

In  the  weapons  system  acquisition  process,  typically  a 
Configuration  Control  Board  (CCB)  has  the  final  approval 
authority  on  change  requests  in  the  system  program.  This 
authority  could  include  construction  change  requests  on 
facilities  supporting  the  weapon  system.  Stahl,  in  his 
article,  "Managing  Engineering  Changes,"  recommends  that 
Configuration  Management  be  established  to  ensure  that  the 
following  six  steps  are  applied  to  engineering  change 
requests.  They  include  the  following: 

1.  Justification  of  the  need. 

2.  Establishing  the  priority. 

3.  Preparing  a  proposal  for  organizations  to  review. 

4.  Reviewing  the  proposal. 

5.  Approving/disapproving  the  proposal  or  concur/ 
nonconcur  in  the  priority. 

6.  Incorporating  the  change  (32:4). 


23 


The  baseline  can  be  managed  by  configuration 
management.  Configuration  management  is  the  process  of 
controlling  and  accounting  for  a  product's  engineering 
design,  from  design  phase  through  delivery.  A  vital  role 
of  configuration  management  is  to  control  changes  to  an 
engineering  design  (40:66) . 

Configuration  management  policy  and  guidance  is  in 
MIL-STD-480,  "Configuration  Control -Engineering  Changes, 
Deviations  and  Waivers."  Among  other  items,  this  guidance 
provides  the  following: 

1.  Requirements  for  maintaining  configuration  control 
of  configuration  items. 

2.  Requirements  for  preparation  and  submission  of 
proposed  engineering  changes  (30:8) . 

In  the  weapon  system  acquisition  process: 

The  difficulty  in  dealing  with  the  user,  regarding 
engineering  changes,  is  in  separating  goals  from 
requirements.  The  relationship  is  clouded  by  changes 
in  personnel,  by  changes  in  requirements  dictated  by 
expanded  missions,  and  by  altered  threats.  (30:16) 

In  examining  the  management  techniques  of  the  A-7D 
System  Program  Office,  Powers  writes  that  configuration 
management  helped  to  separate  goals  and  requirements  and 
forced  adequate  and  timely  evaluation  of  the  user's 
requests  for  changes  (30:17).  Configuration  management 
helped  to  control  a  mixture  of  goals,  opinions,  policies 
and  requirements  by  the  following  methods: 
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1.  Generating  and  maintaining  a  corporate  memory  to 
show  the  source  of  changes. 

2.  Maintaining  change  request  files  to  show  the 
origin  of  need,  description  of  changes,  coordination  levels 
and  estimated  costs  (30:17). 

Configuration  Management  Applications 

Meiners  wrote  a  PhD  dissertation  on  variables  that 
induce  major  changes  to  the  weapon  systems  acquisition 
process.  He  also  states  that  configuration  management  can 
control  major  changes  and  resultant  cost  growths  in  weapon 
systems.  Configuration  management: 

...  is  a  discipline  which  integrates  the  technical 
and  administrative  actions  of  identifying  and 
documenting  the  functional  and  physical 
characteristics  of  an  item  during  its  life  cycle, 
controlling  changes  proposed  to  these  characteristics, 
and  providing  information  on  the  status  of  change 
actions.  (27:69) 

He  writes  that  configuration  management  can  be  thought 
of  as  the  way  managers  can  control,  record,  and  communicate 
the  integrity  and  continuity  of  the  design,  engineering  and 
cost  trade-off  decisions  (27:70). 

In  weapon  systems  acquisitions,  cost  increases  result 
when  poor  management  of  engineering  changes  occurs  (32:3). 
The  weapon  systems  process  uses  configuration  management 
which: 

.  .  .  is  the  engineering  discipline  of  identifying, 
controlling,  accounting  for,  and  auditing  the 
functional  and  physical  characteristics  of  items  .  .  . 

.  Configuration  identification  is  the  discipline  of 


selecting  the  documents  which  identify  and  define  the 
configuration  characteristics  of  an  item.  These 
documents  usually  refer  to  specifications  and 
drawings.  .  .  .  (32:4) 


One  of  the  reasons  to  apply  configuration  management 
is  to  ensure  that  the  change  is  necessary  and  beneficial  to 
the  government.  Configuration  control  provides  a  means  to 
scrutinize  and  prioritize  changes.  Stahl  writes  that 
managers  must  ensure  engineering  changes  meet  one  of  the 
following  criteria:  "...  (l)  correct  deficiencies,  (2) 
satisfy  a  change  in  user  requirements,  (3)  effect 
substantial  life-cycle  cost  savings,  or  (4)  prevent  or 
allow  desired  slippage  in  an  approved  schedule"  (32:4). 

Effective  management  of  engineering  changes  includes 
the  following  steps: 

...  (1)  justify  the  need,  (2)  establish  the  change 
as  Class  I  [typically  impacts  dollars  or  schedule]  or 
Class  II  [does  not  fall  in  Class  I  category],  (3) 
prepare  an  engineering  change  proposal  (ECP) ,  (4) 
submit  to  and  review  by  the  government,  (5)  approve/ 
disapprove  or  concur/nonconcur  in  classification,  and 
(6)  incorporate  the  change  in  the  item  and  data. 

(32:4) 


A  CCB  approves  or  disapproves  all  Class  I  ECP's.  Stahl 
also  writes  that  activities  and  organizations  such  as  those 
involved  with  facilities  that  could  be  affected  by  the 
proposed  change  should  be  on  the  CCB  (32:5). 

Configuration  management  does  not  apply  solely  to  the 
weapons  system  acquisition  process.  Al-Subaiei's  thesis  is 
about  control  of  changes  in  software  maintenance.  To 
incorporate  a  change  into  a  program,  software  project 
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managers  should  ask  the  following:  "Why  is  the  change 
needed?  What  is  the  impact  of  this  change  on  the  rest  of 
the  system?  What  is  the  cost  involved  to  do  the  change? 

How  important  or  complicated  is  this  change?"  (4:56). 

These  questions  should  be  answered  because  incorporating  a 
change  may  introduce  new  errors  into  the  program. 

Sometimes  the  users  may  exaggerate  their  needs.  Some  user 
requests  for  changes  are  not  justifiable  for  cost  or 
technical  reasons  (4:57). 

Guthrie  and  Konkel  wrote  about  project  management 
principles  and  techniques  proven  applicable  to  large 
construction  projects  that  support  multi-billion  dollar 
civilian  programs.  They  state  that  an  essential  part  of 
project  management  is  the  disciplined  control  and 
administration  of  changes  and  revisions.  The  changes  "must 
be  incorporated  as  quickly  as  possible  and  under  strictly 
controlled  procedures"  (22:0.1.3). 

Configuration  Management  in  Air  Force  Construction 

Configuration  management  is  not  a  required  management 
procedure  of  Air  Force  Civil  Engineering  in  construction 
project  design.  This  section  explains  the  change  control 
process  used  in  some  Air  Force  construction  projects. 

Construction  of  the  Aerospace  Propulsion  Test  Facility 
(ASTF)  facilities  is  an  example  of  a  project  that  employed 
configuration  management.  The  ASTF  will  test  jet  engines 
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of  the  future  (35:3).  This  project  falls  under  the  general 
heading  of  Research  and  Development  (R&D) . 

R&D  facilities  have  a  direct  interface  with  flight 
hardware,  hospital  hardware  or  research  and 
development  hardware.  Intensive  management  and  review 
techniques  are  required  on  these  projects.  .  .  .  R&D 
projects  usually  contain  a  deadly  combination  of  high 
cost,  tight  schedule  and  inherent  potential  for 
change.  (35:5-6) 

Congress  funded  the  ASTF  in  fiscal  year  1977  at  $437 
million;  but  by  1982,  the  project  experienced  a  significant 
cost  increase  estimated  at  $138  million  and  a  schedule  slip 
of  36  months  (35:6).  The  simultaneous  contracting,  by  the 
Air  Force,  for  the  government  furnished  equipment  (GFE)  and 
the  construction  ”...  resulted  in  numerous  design 
omissions  and  incomplete  equipment  interface  configuration" 
(36:2).  Because  the  design  lacked  adequate  GFE  interface 
requirements,  to  accommodate  the  GFE  would  require 
extensive  modifications  and  redesign  (36:2). 

Tucker  states  that  the  design  change  process  included 
two  separate  boards  to  approve  changes,  the  CCB  and  the 
Facility  Working  Group  (FWG) .  The  systems  project  manager 
chaired  the  CCB,  which  served  as  interface  control  with  the 
entire  program  and  approved  facility  change  requests 
exceeding  $25  thousand  or  if  the  change  request  interfaced 
with  program  equipment.  The  project  civil  engineer  chaired 
the  FWG,  which  reviewed  and  approved  construction  changes 
below  $25  thousand.  The  ultimate  goal  of  the  construction 
project  manager  was  to  get  the  FWG  or  CCB  to  approve  or 
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disapprove  the  change  request.  After  the  CCB  or  the  FWG 
approved  the  requested  change,  the  construction  agency 
decided  the  best  method  to  incorporate  the  change,  e.g., 
current  contract  versus  follow-on  contract  (35:42-43) . 

The  researcher  concludes  that  Tucker  believes  that 
configuration  management  helped  to  manage  problems  created 
by  concurrent  facility  and  GFE  contracting.  Even  though 
the  cost  increases  were  significant  configuration 
management  helped  to  reduce  cost  increases  and  minimize 
schedule  delays. 

Below  is  a  discussion  of  three  facility  management 
plans  that  address  control  of  user  changes  in  construction. 

The  AFRCE  -  BMS,  General  Instructions  for  MCP  Designs 
and  Construction.  FY  89  and  Bevond.  addresses  control  of 
changes.  This  document  states: 


Congressional  and  Department  of  Defense  reviews  have 
resulted  in  concerns  that  too  many  change  orders  are 
being  implemented  ....  HQ  USAF  has  directed  Air 
Force  field  organizations 
to  restrict  change  requests  to  mission  essential 
changes  or  changes  to  make  the  facility  usuable  for 
its  intended  purpose.  Facility  Change  Board  operating 
procedures  shall  be  used  for  all  construction  change 
requests.  (2:11) 


The  second  facility  management  plan,  the  Intensive 
Management  Plan  for  the  Medical  Clinic  Replacement 
Facility.  Kirkland  AFB.  states: 


Those  changes  which  are  necessary  to  the  fulfillment 
of  the  mission  and/or  necessary  to  permit  construction 
to  proceed  on  an  orderly  basis  will  be  considered  for 
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immediate  implementation.  Non-mandatory  changes  can 
be  deferred  for  implementation  by  separate  procurement 
action.  Deferred  changes  will  be  reconsidered  after 
all  mandatory  items  have  been  incorporated  and  the 
construction  work  is  substantially  complete.  (3:8) 

The  third  facility  management  plan,  the  B-IB  Support 
Facilities  Construction  Management  Plan,  states  that: 

During  the  design  phase,  the  configuration  of  B-IB 
facilities  will  be  based  on  the  functional  criteria 
provided  by  AFRCE-SAC  in  the  original  design 
instructions  as  modified  during  the  design  process. 

All  changes  made  to  the  plans  and  specifications  after 
construction  contract  award  will  be  in  accordance  with 
established  control  procedures.  (1:11) 

This  plan  states  that  three  types  of  requests  exist 
based  on  usability,  schedule  or  cost  impacts.  The  first 
type  is  called  a  "Class  1"  change.  These  changes  have  a  ". 
.  .  significant  impact  on  either  usability,  costs  or 
schedules"  (1:11).  A  "Class  2"  change  is  "A  mandatory 
change  that  must  be  made  for  the  facility  to  function" 
(1:11).  A  "Class  3"  change  is  ".  .  .  any  user  originated 
change  that  does  not  meet  the  definition  of  a  Class  1 
change"  (1:11). 

In  addition,  the  originator  of  the  request  recommends 
the  change  priority  (either  urgent  or  routine) .  The  base 
civil  engineer  and  site  activation  task  force  validate  this 
priority.  The  originator  prepares  a  letter  with  this  item 
and  the  following  information  about  the  request:  detailed 
description,  justification,  recommended  reason  for  change, 
and  signature  of  functional  commander  (1:14). 
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It  is  evident  that  some  Air  Force  projects  have,  at 
least,  a  general  process  identified  to  evaluate  requested 
changes.  These  projects  use  configuration  management  in 
varying  degrees  to  implement  the  evaluation  process. 

Impacts  of  Changes  in  Construction 

DeFeis  writes  that  as  competition  increases  among 
construction  contractors,  the  bids  become  tighter  and 
profit  margins  decline.  These  contractors  are  dependent  on 
change  orders  to  make  a  profit  (9:16). 

Rosmond's  findings  are  similar  in  his  "Analysis  of  Low 
Bidding  and  Change  Order  Rates  for  Navy  Contracts."  He 
states  that  the  customer-requested  change  order  is  a  way 
for  the  contractor  to  make  opportunity  profits.  He  also 
reported  that  a  Defense  Audit  Service  audit  in  1982 
attributed  eleven  percent  of  change  orders  in  construction 
projects  to  user  requests  for  changes  (31:28). 

Halpin  studied  the  frequency  and  magnitude  of 
construction  time  overruns.  He  surveyed  221  MILCON 
projects  (from  the  Air  Force  and  Army)  completed  between 
July  1967  and  June  1970.  He  reported  that  user  changes 
were  the  second  most  used  reason  to  extend  construction 
contracts  (the  first  reason  is  design  deficiencies) . 

Halpin  defined  user  time  extensions  as  " .  .  .  extensions 
caused  by  changes  requested  by  the  using  agency"  (23:2). 
These  user  changes  accounted  for  an  average  contract 
extension  length  of  5.3  percent  (of  specified  contract 
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time) ,  as  compared  to  an  average  contract  extension  length 
of  25.3  percent  for  all  possible  reasons  (23:8).  His 
conclusion  is  that  "Reduction  of  designer  error/changes  and 
user  errors/ changes  would  contribute  most  to  decreasing 
construction  time"  (23:13). 

Mogreen  recently  studied  the  causes  and  costs  of 
changes  to  military  construction  contracts.  He  selected  25 
construction  projects  completed  or  under  construction  from 
1  Jan  1984  to  30  June  1985.  These  projects  were 
administered  by  the  Corps  of  Engineers  on  Army 
installations  (28:4).  He  concluded  that  the  primary  causes 
of  cost  modifications  on  the  projects  studied  were  design 
deficiencies  (36.3  percent),  user  change  requests  (22.3 
percent),  and  unknown  site  conditions  (21.8  percent) 
(28:49,56). 

Mogreen  also  wrote  that: 


Functional  reviews  by  the  installation  are  essential 
to  reducing  user  requested  modifications.  In  general, 
it  appeared  that  poor  project  scope  definition  was  a 
major  contributor  to  user  requested  changes.  Projects 
were  designed  and  let  out  for  bid  without  a  firm  scope 
definition  being  communicated  to  the  designer  or 
user.  Consequently,  the  designer  may  not  have  been 
aware  of  what  the  customer  wanted  and  the  customer  not 
aware  of  what  was  designed  until  construction  actually 
began.  This  problem  was  aggravated  by  personnel 
rotations  at  the  installation  which  often  resulted  in 
the  ultimate  user  being  unfamiliar  with  design 
decisions  made  by  his  predecessor.  (28:82) 


Mogreen  surveyed  project  engineers  and  reported  that 
practically  all  agreed  to  the  need  for  design  reviews 
either  "always"  or  "most  of  the  time,"  regardless  of  the 
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project  size.  Also  he  reports  that  three-fourths  of  the 
respondents  feel  that  reviews  save  the  government  money 
"always"  or  "mostly"  (28:87). 

Mogreen  comments  that  checklists  could  be  used  as 
review  aids  and  could  standardize  reviews.  However,  he 
comments  that  checklists  are  not  widely  distributed  and 
seldom  used.  Slightly  over  half  the  respondents  he 
surveyed  said  that  checklists  are  rarely  or  never  available 
to  reviewers.  Even  having  a  checklist  on  hand  would  not 
guarantee  its  use  (28:96-97). 

Chapter  Summary 

The  project  book  represents  the  initial  baseline  for 
construction  blueprints  and  specifications.  The  baseline, 
which  consists  of  user  requirements,  should  be  finalized 
when  the  design  is  35  percent  complete. 

The  literature  consistently  reports  that  user  change 
requests  delay  design  and  construction  time,  and  increase 
costs.  Researchers  have  determined  that  contractors  (both 
design  and  construction)  sometimes  rely  on  change  orders  to 
recover  costs  lost  in  other  parts  of  the  contract.  In 
addition,  the  literature  consistently  states  the  need  for 
in-place  measures  to  control  and  evaluate  user  change 
requests. 

Standardized  procedures  to  manage  user  change  requests 
applies  to  other  customer  oriented  operations,  such  as  the 
weapon  systems  acquisition  process  and  software 
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development.  These  standardized  procedures  are  controlled 
by  configuration  management.  Configuration  management 
helps  to  control  changes  and  cost  growths  in  weapon  system 
projects.  This  literature  review  showed  that  several  large 
Air  Force  construction  projects  instituted  control  measures 
on  user  requested  changes.  These  control  measures  are  not 
specifically  identified  as  "configuration  management"  but 
the  process  and  purpose  are  essentially  the  same. 

Next  Chapter  of  Thesis 

Chapter  III  (Methodology)  presents  the  steps  to 
collect  and  analyze  the  research  data.  This  data  will 
address  the  problem  statement  and  research  objectives. 


Ill .  Methodology 

Chapter  Overview 

This  chapter  presents  the  steps  that  the  research 
employs  to  address  the  problem  statement  and  research 
objectives.  This  research  uses  a  "reason  analysis”  as  a 
guide  to  study  the  evaluation  of  user  requested  changes  in 
MILCON  projects.  Each  of  the  five  stages  of  reason 
analysis  and  how  they  relate  to  this  research  are  explained 
in  this  chapter.  This  chapter  also  explains  the  process  to 
draft  the  questionnaire  used  in  gathering  the  research 
data,  and  the  selection  process  for  the  personnel 
interviewed  in  this  research. 

Reason  Analysis 

The  objectives  of  this  research  are  the  following: 

1.  To  identify  effective  decision-making  factors 
used  in  the  evaluation  of  user  change  requests. 

2.  To  arrange  these  factors  in  a  format  that  civil 
engineering  project  managers  can  use. 

3.  To  recommend  ways  to  implement  these  factors. 

This  research  studies  the  factors  that  cause  the  project 
manager  to  approve  or  reject  a  requested  change  by  the  user 
to  the  facility  design  or  construction.  An  effective 
approach  can  be  used  to  determine  the  causal  relationships 
to  assess  the  causes  of  people's  actions  and  "reasons  for.” 
This  approach  is  called  a  "reason  analysis”  (21:223). 
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other  individuals  wrote  more  on  the  valid  use  of 
reason  analysis  to  explain  intentions  or  actions  of 
individuals.  Kadushin  reports,  in  his  article,  that 
Lazarsfeld  defined  reason  analysis  as  .  .a  set  of 
procedures  used  in  survey  research  to  construct  a  causal 
explanation  for  the  actions,  decision,  or  intentions  of 
individuals”  (24:338).  Kadushin  also  identifies  when  to 
apply  reason  analysis.  He  states  that: 


Reason  analysis  can  always  be  used  in  studying  the 
subjective  factors  in  any  course  of  individual  action. 
.  .  .  If  one  wants  to  know  how  an  action  came  to  be- 
what  steps  were  taken  and  what  the  key  choices  were 
.  .  .  then  no  technique  other  than  reason  analysis  can 
be  used.  .  .  .  Reason  analysis  is  usually  concerned 
with  acts  that  involve  some  sort  of  conscious 
decision;  habitual  acts  are  probably  not  suited  for 
any  of  these  models.  (24:338) 


Stages  of  Reason  Analysis 

Kadushin  states  that  designing  a  reason  analysis 
consists  of  several  stages.  Below  is  a  discussion  of  these 
stages. 


First,  types  of  action  involved  in  the  subject  to  be 
studied  are  distinguished  one  from  another;  second, 
the  act  is  divided  into  phases  or  separate  acts,  if 
this  is  necessary;  third,  an  accounting  scheme  is 
developed  for  each  act  or  phase;  fourth,  the 
accounting  scheme  is  translated  into  a  data-collection 
guide  .  .  .  ;  fifth,  a  calculus  of  factors  must  be 
developed  so  that  the  relative  weight  of  different 
factors  can  be  assessed.  Finally,  the  results  of  this 
assessment  are  tabulated  for  the  sample  as  a  whole  or 
for  different  segments  of  it.  (24:340) 


First  Stage.  The  first  stage  of  the  reason  analysis 
is  to  formulate  a  purpose  and  select  boundaries  of  the 


36 


research.  Zeisel's  concept  must  be  applied  to  this 
research.  At  first  glance,  if  we  set  out  to  explore  a 
person's  motives,  then  their  whole  life  history  and 
physical  environment  would  lie  behind  their  decisions  in 
evaluating  a  user  requested  change.  It  is  impossible  to 
evaluate  all  these  reasons  (39:155).  However,  this 
research  includes  the  most  important  issues  that  could 
identify  explanations  for  the  action,  decisions,  and 
intentions  of  project  managers  when  evaluating  a  user 
change  request.  This  research  is  thus  limited  to  the 
following  research  questions: 

1.  Determining  the  factors  to  use  to  evaluate  change 
requests . 

2.  How  should  the  factors  vary  based  on  the  project 
status. 

3.  How  should  the  factors  be  weighed. 

4.  What  formal  approval  procedures  should  the  project 
manager  use  to  process  the  requests 

5.  What  organizations  should  the  user  change  request 
be  coordinated  with. 

6.  Do  any  existing  decision  support  systems  address 
how  to  evaluate  requested  changes. 

Second  Stage.  The  second  stage  of  reason  analysis  is 
to  decide  on  the  types  of  action  the  research  will 
investigate.  Learning  different  varieties  of  types  of 
behavior  comes  from  accumulated  knowledge,  common  sense, 
and  informal  interviewing  (39:156-157).  A  review  of  the 
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literature  provides  a  starting  point  to  acquire  knowledge. 
However,  only  a  portion  of  the  existing  knowledge  in  any 
field  is  in  literature,  thus,  the  researcher  expects  that 
only  a  small  portion  of  current  knowledge  of  evaluating 
user  change  requests  may  be  on  paper.  The  next  logical 
step  is  to  solicit  ideas  from  those  believed  to  know  what 
is  going  on  (20:84). 

Time  prevented  the  use  of  a  survey  to  solicit 
individual  ideas.  Instead,  the  questionnaire  pretest  phase 
of  this  research  included  soliciting  comments  from  the 
participants  on  the  questionnaire  itself.  The 
"Questionnaire  Testing"  section  of  this  chapter  discusses 
the  pretest  of  the  questionnaire. 

Third  Stage.  The  third  stage  of  reason  analysis  is  to 
develop  an  accounting  scheme.  The  accounting  scheme  is 

.  .an  organized  list  of  factors  that  are  believed  to  be 
relevant  causes  of  influences  upon  some  action,  opinion,  or 
intention"  (21:224).  Further,  Zeisel  states  that  the 
accounting  scheme: 

.  .  .  guides  the  collection  of  information  and 
provides  the  framework  for  its  interpretation. 

Without  such  a  generalizing  device  .  .  .  individual 
decisions  cannot  be  subjected  to  quantitative 
analysis;  hence  no  generalizations  can  be  made.  .  .  . 
(39:159) 

The  accounting  scheme  will  be  used  to  structure  the 
replies  from  the  experts  on  evaluating  user  requested 
changes  in  quantitative  statements  and  about  the  decision¬ 
making  process  in  general. 
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Zeisel  stated  that  "The  accounting  scheme  provides  the 
structure  of  the  questionnaire.  .  .  (39:188).  The 

researcher  developed  the  accounting  scheme  through 
pretesting  of  the  questionnaire,  which  the  "Questionnaire 
Testing"  and  "Questionnaire  Drafting"  sections  of  this 
chapter  discuss. 

Questionnaire  Drafting.  The  questionnaire  is  the 
instrument  to  gather  data  to  understand  the  motives  and 
causes  of  people's  act  ons  when  evaluating  change  requests. 
Clover  notes  that  using  the  why  approach  on  questionnaires 
is  necessary  to  know  the  reasons  for  people's  actions 
(7:147).  However,  he  states  that: 


Some  researchers  believe  that  there  is  little  of  value 
that  can  be  learned  from  persons  by  asking  them  why 
they  do  what  they  do.  It  is  contended  that  people  are 
unable  to  give  actual  reasons  because  basically  human 
beings  are  irrational  creatures.  .  .  .  According  to 
this  view,  a  person  should  be  asked  only  for  facts 
that  can  be  quickly  established,  and  can  be  given 
mostly  in  simple  "yes"  or  "no"  answers.  (7:147) 


To  address  this  concern,  Clover  states: 


.  .  .  if  it  is  necessary  to  obtain  information  about 
reasons  for  the  actions  of  persons  and  some  measure  of 
the  relative  importance  of  the  different  reasons,  it 
is  altogether  possible  that  some  useful  results  can  be 
secured  by  a  correctly  conducted  questionnaire  survey. 
(7:147) 


Lazarsfeld,  as  reported  by  Clover,  identified 
important  conditions  in  "the  art  of  asking  why."  First, 
the  researcher  must  realize  that  there  are  many  reasons  for 
why  people  act  as  they  do.  Zeisel  further  states  that  just 
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asking  why  in  the  research  may  bring  disappointing  results. 
There  are  so  many  possible  answers  that  we  could  not  know 
how  all  these  reasons  fit  together  (39:153).  It  is  then 
important  that  the  researcher  understand  the  second 
condition  in  "the  art  of  asking  why."  The  second  condition 
is  that  all  the  reasons  fall  into  one  of  three  following 
classifications;  tendencies,  influences,  and  attributes 
(7:150-151).  All  three  classifications  are  explained 
below.  The  third  and  final  condition  "in  the  art  of  asking 
why"  is  that  "The  researcher  must  know  how  to  use  his 
knowledge  about  this  three-fold  classification"  (7:151). 

Tendencies  is  the  first  classification  that  explains 
why  people  act  as  they  do.  Tendencies  include  physical  and 
mental  characteristics  of  the  interviewee  (7:151).  For 
example,  a  project  manager  might  not  include  a  change 
request  because  his  past  experience  leads  him  to  believe 
the  change  request  is  not  feasible  for  one  reason  or 
another.  Zeisel  refers  to  this  condition  as 
"predispositions."  Predispositions  concern  personnel 
motives  prior  to  the  action.  Zeisel  uses  an  example  of 
purchasing  a  cold  cream.  A  person's  predispositions  could 
range  from  a  desire  to  have  more  beautiful  hands,  to  being 
less  lonesome,  or  being  more  healthy  (39:158-159). 

The  second  classification  that  could  explain  why 
people  act  as  they  do  is  influences  (7:151).  Influences 
represent  the  external  forces  which  cause  a  person  to  act 
the  way  he  does.  For  example,  the  project  manager  may 
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require  a  third  organization  approval  (i.e.,  influence  of 
the  third  organization)  on  the  user  requested  change,  as 
spelled  out  in  a  management  plan,  before  he  approves  the 
request . 

The  third  classification  explaining  why  people  act  as 
they  do  is  attributes.  Attributes  are  the  features  of  the 
commodity  such  as  price,  size,  color,  shape  (7:151).  For 
example,  the  project  manager  may  approve  or  disapprove  the 
user  change  request  because  of  the  dollar  value  "attribute" 
of  the  change  request. 

Questionnaire  Testing.  Emory  recommends  after 
drafting  the  questionnaire,  to  test  it  on  persons  typical 
of  the  design  population  (21:206).  Clover  reports  that 
experienced  investigators  know  that  pretesting,  in  the  long 
run,  saves  time  and  money  (8:142). 

An  important  research  issue  was  how  much  pretesting  is 
needed  to  develop  a  sufficient  questionnaire.  Many  factors 
impact  the  issue  to  determine  the  number  of  pretests. 

Clover  states  that  one  reason  to  pretest  the  questionnaire 
is  so  that  interviewers  can  be  selected  (8:142).  Only  one 
researcher  will  conduct  all  interviews,  thus  there  is  no 
need  to  pretest  for  this  reason. 

Clover  states  another  factor  to  determine  the  number 
of  pretests  is  the  nature  and  complexity  of  the 
questionnaire.  Only  15  to  20  pilot  interviews  are 
sufficient  to  identify  most  of  the  revisions  needed  in  a 
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simple  questionnaire.  Only  five  to  six  interviews  could  be 
"enlightening”  in  testing  a  questionnaire  (8:142). 

The  researcher  tested  the  questionnaire  on  graduate 
students  with  design  and/or  construction  project  management 
experience  in  the  Graduate  Engineering  Management  Program 
at  the  Air  Force  Institute  of  Technology  (AFIT)  and  on 
construction  and  engineering  project  managers  in  the 
Headquarters  Air  Force  Logistics  Command  (AFLC) .  The  first 
pretest  involved  five  graduate  students.  The  researcher 
wanted  to  do  two  pretests  and  estimated  ten  students  had 
experience  in  design  and  construction  management.  Thus, 
each  pretest  involved  five  students.  While  these  graduate 
students  may  not  be  experts,  they  have  experience  in  either 
design  or  construction  management  and  therefore  were 
considered  to  be  a  valid  test  group.  The  cover  letter  to 
the  initial  questionnaire  stated  the  research  problem 
statement  and  objectives  then  asked  the  participants  to 
consider  the  following; 

1.  Can  the  interviewee  can  answer  all  questions? 

2.  Is  there  a  logical  sequence  of  questions? 

3 .  Do  the  questions  have  a  proper  balance  between 
generality  and  specificity? 

4 .  Is  the  question  clear  or  the  wording  biased? 

5.  Should  questions  be  added  or  eliminated,  other 
suggestions? 

To  obtain  comments,  the  researcher  discussed  the 
questionnaire  with  each  graduate  student.  The  researcher 
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incorporated  their  comments  into  another  draft  of  the 
questionnaire . 

This  revised  questionnaire  served  as  the  basis  to 
conduct  semi-structured  interviews  on  the  second  group  of 
AFIT  graduate  students.  Again,  while  these  graduate 
students  may  not  be  experts,  they  have  experience  in  either 
design  or  construction  management  and  therefore  were 
considered  to  be  a  valid  test  group. 

After  interviews  with  this  second  group  of  AFIT 
students,  the  researcher  incorporated  their  comments  into 
what  the  researcher  believed  was  a  final  version  of  the 
questionnaire.  Headquarters  AFLC  supervisory  personnel  in 
Engineering  and  Services  recommended  six  personnel  in 
design  and  construction,  with  sufficient  experience,  that 
would  be  excellent  for  the  research.  However,  the 
interviews  with  six  design  and  construction  project 
managers  at  Headquarters  AFLC  revealed  inaccuracies  and 
misunderstandings  in  the  questionnaire.  The  researcher 
decided  to  incorporate  their  comments  into  a  second  final 
version  of  the  questionnaire. 

As  a  summary,  the  researcher  developed  the 
questionnaire  through  three  different  versions  and 
conducted  sixteen  trial  interviews.  This  questionnaire 
represents  the  accounting  scheme  for  the  "reason  analysis." 
Appendix  A  contains  the  final  interview  questions. 

Fourth  Stage.  The  forth  stage  in  the  reason  analysis 
process  is  the  actual  interviewing  (39:171).  Below  is  a 


43 


description  of  the  universe,  population,  and  sample  of 
participants  relevant  to  this  research.  This  stage  also 
includes  a  description  of  the  data  gathering  process. 

The  Universe.  The  universe  for  this  research 
consists  of  all  Air  Force  personnel  who  are  design  or 
construction  project  managers.  These  personnel  could  be 
assigned  to  either  engineering  design  or  construction 
management  offices  in  Civil  Engineering.  These  personnel 
may  be  at  the  MAJCOM,  AFRCE,  or  base  level  Civil 
Engineering  agencies. 

The  Population.  The  population  of  interest  is 
the  group  of  "experts”  who  use  effective  methods  that 
determine  cost,  schedule,  and  other  impacts  of  user  change 
requests.  Frequent  processing  of  user  requested  changes 
provides  experience  to  the  project  manager  who  could  become 
an  expert.  This  processing  starts  when  the  request  is 
first  identified  and  ends  when  the  request  is  incorporated 
in  the  construction  project. 

The  Sample.  Stone  writes  that  research  can 
include  hand  picked  elements  in  the  sample  (called 
purposive  sampling) ,  provided  the  sample  is  satisfactory 
considering  the  needs  of  the  study  (34:81).  This  research 
employs  purposive  sampling  because  of  the  need  to  interview 
"experts"  who  employ  methods  that  successfully  evaluate 
impacts  of  user  change  requests.  The  sample  can  be 
considered  hand  picked  because  the  researcher  selected  two 
of  the  four  AFRCEs  and  a  single  MAJCOM  to  provide  the 
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sample  elements.  In  turn,  the  engineering  design  and/or 
construction  management  supervisors  at  these  offices 
selected  qualified  project  managers  for  the  interviews. 

The  AFRCE  and  MAJCOMs  typically  have  the  largest 
concentration  of  design  construction  project  managers  at  a 
single  location.  This  concentration  provided  a  logistical 
advantage  (e.g.,  saves  travel  time)  for  the  research. 

Data  Gathering  Process.  Stone  writes  that 
interviews  consist  of  the  researcher  presenting  the 
questions  and  recording  the  elicited  responses  (34:67). 

The  elicited  responses  are  in  Appendix  B.  Sometimes  the 
interviewees  discussed  examples  or  information  not  relevant 
to  the  research.  This  information  is  not  in  Appendix  B. 

This  research  consisted  of  semi-structured  interviews 
that  involve  face-to-face  interaction  or  the  use  of  the 
telephone.  In  a  semi-structured  interview  (or  sometimes 
called  an  open-ended  interview) ,  the  respondent  can  "answer 
a  predetermined  set  of  questions  in  any  manner  he  or  she 
chooses"  (34:68),  The  semi-structured  interviews  consisted 
of  questions  allowing  for  some  dichotomous  responses  (e.g., 
yes  or  no) ,  and  open-ended  questions  allowing  the 
interviewee  to  answer  any  way  they  choose  (34:68).  These 
open-ended  questions  can  be  used  when  the  nature  of  the 
research  is  to  discover  opinions  and  degrees  of  knowledge 
(21:217) . 

This  data  gathering  format  applies  to  developing  a 
hypotheses  rather  than  testing  of  a  hypothesis  (34:68). 
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The  objective  of  this  research  is  to  identify  effective 
methods  to  evaluate  user  change  requests  in  design  or 
construction;  the  objective  is  not  to  test  any  specific 
model  used  to  evaluate  change  requests. 

Stone  also  points  out  that  the  interviewing  technique 

.  may  not  lead  to  as  thorough  an  understanding  of  the 
phenomenon  under  investigation  as  alternative  data 
collection  methods  .  .  (34:69).  For  example,  he  states 

that  sometimes  the  interpersonal  nature  of  the  interview 
process  may  influence  the  interviewee  attitudes  (34:69). 

The  researcher  tried  to  avoid  this  and  other  common 
pitfalls. 

The  researcher  conducted  face-to-face  interviews. 
Experience  shows  that  these  interviews,  held  in  a  relaxed 
environment,  promote  the  interviewee  to  open  up  and  discuss 
the  topic  (21:217-218).  This  open  environment  provided  the 
researcher  the  opportunity  to  probe  over  the  responses. 
Zeisel  states  that  during  an  interview  a  problem  could 
occur  because  the  respondent  thinks  he  is  providing  a 
satisfactory  answer,  while  the  researcher  may  not  consider 
his  answer  satisfactory.  Probing  can  be  accomplished 
through  cross-examination.  Zeisel  points  out  that  the 
interviewer  lacks  the  legal  authority  of  an  attorney,  thus 
this  research  must  employ  tact  and  psychological  empathy 
(39:172).  Zeisel  states  "The  general  rule  for  probing  is 
to  recognize  that  the  final  choice  is  the  end  point  of  a 
funnel  of  successively  narrowing  alternatives”  (39:174). 
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Fifth  Stage.  Zeisel  states  that  after  the 
interviewing  is  done,  the  fifth  and  last  stage  of  the 
reason  analysis  is  the  task  of  counting  and  suromarizing 
(39:182).  Kadushin  states  that  this  stage  is  the  most 
difficult  part  of  a  reason  analysis  because  assessment  of 
cause  and  meaning  must  be  performed  (24:341). 

To  begin  the  analysis,  the  questionnaire  results  are 
tabulated.  A  large  number  of  "no  answers”  to  the 
questionnaire  used  in  this  research  would  reflect 
unsuccessful  or  unsystematic  interviewing  (39:182). 

Kadushin  states  that  causes  cannot  be  assessed  by 
comparing  actors  to  nonactors.  This  means  effective 
methods  of  evaluating  user  change  requests  can  not  be 
determined  by  comparing  responses  of  project  managers  who 
effectively  manage  user  change  requests  to  project  managers 
who  do  not  effectively  manage  user  change  requests.  The 
following  three  strategies  are  possible  to  assess  cause: 

(1)  get  the  actor  to  do  so,  (2)  use  the  clinical  judgement 
of  the  researcher,  and  (3)  reduce  the  number  of  factors 
into  a  smaller  set  (24:340). 

The  researcher  will  use  the  second  and  third 
strategies  from  above  (i.e.,  rely  on  personal  judgement  and 
reduce  the  factors  into  a  smaller  set) .  The  data  analysis 
will  include  developing  an  understanding  of  the  key  factors 
in  the  evaluation  of  change  requests.  A  frequency  analysis 
will  be  used  to  identify  key  factors  and  key  decision¬ 
making  points.  The  researcher  will  use  these  factors  and 
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decision-making  points  to  determine  if  they  can  be  arranged 
in  a  useful  format  for  project  managers.  One  useful  format 
is  the  flowchart. 

Lucas  in  his  book,  Information  Systems  Concepts  for 
Management .  states  that  flowcharts  are  a  graphical 
technique  that  facilitate  design  in  an  information  system 
(25:307).  Also,  he  states  that  flow  charts  depict  the 
following:  (1)  knowledge  and  decision  rules,  and  (2)  where 

the  data  is  created  and  manipulated  in  processing 
information  (25:429,310).  If  the  factors  cannot  be 
arranged  in  a  flow  chart  format,  then  the  possibility  of 
using  a  checklist  will  be  examined. 

Chapter  Summary 

This  research  employs  a  reason  analysis  methodology  to 
assess  causes  of  project  managers  actions  when  evaluating 
user  change  requests  in  design  and  construction.  Reason 
analysis  will  be  used  to  establish  a  hypothesis  and  assess 
"reasons  for,"  rather  than  the  testing  a  specific 
hypothesis. 

Reason  analysis  consists  of  five  stages.  These  stages 
are  the  following:  (1)  select  boundaries  to  the  research, 
(2)  select  the  actions  to  investigate,  (3)  develop  an 
accounting  scheme,  (4)  conduct  actual  interviews,  and  (5) 
analyze  the  data. 

Development  of  the  accounting  scheme  is  a  critical 
stage.  An  accounting  scheme  provides  the  structure  for  the 
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questionnaire.  This  questionnaire  was  pretested  three 
times  before  the  data  collection  stage. 

The  researcher  will  conduct  interviews  with  project 
managers  at  two  AFRCEs  and  one  MAJCOM.  The  research  will 
consist  of  face-to-face  and  telephone  interviews  in  a  semi- 
structured  format.  The  semi-structured  format  allows  the 
interviewee  to  respond  to  a  predetermined  set  of  questions 
any  way  they  choose.  This  open  environment  also  allows  the 
researcher  to  "probe"  over  the  interviewee  responses. 

Next  Chapter  of  Thesis 

Chapter  IV  (Results)  presents  the  information 
collected  during  the  interviews.  These  results  form  the 
basis  to  develop  conclusions  in  later  chapters. 
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IV.  Results 


Chapter  Overview 

The  purpose  of  this  research  is  to  identify  procedures 
that  design  and  construction  project  managers  can  use  to 
evaluate  user  requested  changes.  These  changes  will  help 
acquire  quality  facilities  to  enhance  user  productivity. 

But  the  project  manager  must  balance  quality  to  project 
execution  (on  time  and  within  available  resources) . 

This  chapter  presents  the  results  of  the  data 
gathering  process  as  described  in  Chapter  III.  The 
percentages  and  frequency  counts  of  the  interview  responses 
are  the  basis  from  which  the  data  analysis  and  conclusions 
are  developed  in  Chapters  V  and  VI,  respectively. 

This  chapter  is  divided  into  two  parts.  The  first 
part  describes  the  demographics  of  the  research  interviews. 
The  second  part,  which  is  the  major  part  of  this  chapter, 
reports  the  interviewee  responses  to  the  six  investigative 
questions  posed  in  Chapter  I. 

Distribution  of  Interviewees 

The  research  includes  a  total  of  27  interviews.  Their 
responses  are  provided  in  Appendix  B.  To  safeguard  the 
anonymity  of  all  interviewees,  the  researcher  omitted  any 
name  references  to  the  source  of  Appendix  B  data.  A 
summary  of  the  interviewee  demographics  is  the  following: 
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Location 


Number  interviewed 


AFRCE  -  Central  Region 

11 

Headquarters  SAC/ DEE 

12 

AFRCE  -  Ballistic 

Missile  Support 

4 

Total 

27 

The  research  eliminated  1  of  the  27  interview 
responses  because  this  interviewee  lacked  experience  in 
evaluating  user  change  requests.  The  remaining  26 
interview  responses  are  the  basis  for  this  chapter's 
percentages  and  frequency  counts. 

The  research  questionnaire  included  two  types  of 
interview  questions.  The  first  type  is  a  structured 
question,  typically  answered  by  either  "yes"  or  "no."  The 
second  type  is  an  open-ended  question. 

The  responses  for  the  structured  interview  questions 
could  be  summed  fairly  easily,  except  when  the  interviewees 
answered  with  a  qualified  "yes"  or  "no."  Summing  the 
responses  to  the  open-ended  questions  was  more  difficult. 
The  researcher  abbreviated  some  of  these  responses  to 
tabulate  the  main  ideas  in  a  frequency  analysis. 

Characteristics  of  the  Questionnaire  Responses 

Research  Question  1.  Research  question  1  is  "What 
factors  should  be  used  to  evaluate  change  requests?" 
Interview  Questions  3a,  3b,  3c,  3d,  3e,  3f,  3g,  3i,  3 j ,  3k, 
31,  3m,  7e,  and  7f  of  the  questionnaire  address  this 
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research  question.  The  responses  to  these  interview 
auestions  are  discussed  below. 

Interview  Questions  3a  and  3c.  These  questions 
were  designed  to  identify  the  percentage  of  interviewees 
who  were  familiar  (i.e.  had  a  working  knowledge)  with  Air 
Force  guidance  on  evaluating  user  change  requests.  Table 
4.1  presents  the  percentages  of  personnel  familiar  with  the 
two  most  recent  versions  of  AFR  89-1. 

Table  4 . 1 

Percentages  of  Interviewees  Aware  of  Guidance  in 


20  Jun  78 

and  1  Nov  88 

Versions 

of  AFR  89 

-1 

AFR  89-1 

Version 

Familiar 

Percent 

Not 

Familiar 

Percent 

20  jr \in  *7  8 

22 

84.6 

4 

15.6 

1  Nov  88 

20 

76.9 

6 

23.1 

The 

slightly 

lower  percentage  for 

the  newer 

version  of 

AFR  89-1  suggests  that  some  interviewees  have  not  reviewed 
this  newer  version  because  of  its  relatively  recent 
publication.  Some  interviewees  also  stated  that  they  were 
aware  of,  but  had  not  seen,  the  new  version  of  AFR  89-1. 

Interview  Questions  3d  and  3e.  For  those 
respondents  familiar  with  the  outdated  version  of  AFR  89-1, 
the  questionnaire  asked  did  they  follow  the  regulation's 
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Table  4.3  presents  a  frequency  count  of  the  various 
items  of  specific  guidance  that  the  22  interviewees 
followed  from  the  20  June  1978  version  of  AFR  89-1. 

Table  4.3  indicates  that  the  most  frequent  response  of 
respondents  who  followed  the  previous  version  of  AFR  89-1 
is  that  the  interviewees  could  not  recall  any  specific 
guidance  they  followed. 
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Table  4.3 

Frequency  Table  for  Specific  Guidance  Followed  from 
the  20  Jun  78  Version  of  AFR  89-1 


Response 

Count 

Percent 

Approval  process  to  handle 
modifications 

3 

13.6 

Funding  guidance 

2 

9.1 

Correspondence  with  other 
agencies 

1 

4.5 

Determination  of  mission 
essentialness 

2 

9.1 

Timely  implementation 

1 

4 . 5 

Could  not  recall  specific 
criteria 

7 

31.2 

Interview  Question  3b.  This  question  asked  those 
20  respondents  familiar  with  the  current  version  of  AFR  89- 
1  (from  Table  4.1)  how  much  guidance  this  version  provided 
as  compared  to  other  sources  when  evaluating  user  requested 
changes.  Respondents  selected  from  one  of  four  possible 
choices;  (1)  large  amount,  (2)  fair  amount,  (3)  small 
amount,  or  (4)  none  of  the  interviewee's  guidance.  Table 
4.4  presents  the  percentages  of  the  interviewees  responding 
to  each  choice. 

Table  4.4  indicates  that  the  current  version  of  AFR 
89-1  provides  little  or  no  guidance  to  three-quarters  of 
the  interviewees.  Perhaps  an  explanation  is  that  the 
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Table  4.4 


1  Nov  88  Version  of  AFR  89-1  Guidance  Amounts 
to  Interviewees 


Response 

Count 

Percent 

Large  amount  of  guidance 

1 

5 

Fair  amount  of  guidance 

4 

20 

Small  amount  of  guidance 

12 

60 

No  guidance 

3 

15 

current  version  of  AFR  89-1  "...  gives  increased 
flexibility  to  the  MAJCOMs  for  design  and  construction  of 
their  programs  [design  and  construction  management].  .  .  .” 
(11:24) . 

Table  4.4  shows  the  need  to  ask  design  and 
construction  project  managers  what  factors  they  use  to 
evaluate  user  requested  changes.  Interview  Questions  3f 
and  3g  gather  data  on  these  additional  factors. 

Interview  Questions  3f  and  3q.  These  questions 
asked  the  interviewee  if  they  use  any  additional  factors 
(Interview  Question  3f)  and  to  identify  these  factors 
(Interview  Question  3g) . 

The  respondents  could  select  from  one  of  two  choices 
(either  yes  or  no)  for  Interview  Question  3f.  All  26 
interviewees  said  "yes"  that  they  use  additional  factors, 
other  than  AFR  89-1,  to  evaluate  user  requested  changes.  A 
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very  high  percentage  is  expected  because  Table  4 . 4  shows 
that  three-fourths  of  the  interviewees  stated  that  the 
current  version  of  AFR  89-1  provides  little  or  no  guidance 
to  evaluate  user  requested  changes. 

Appendix  C  presents  a  frequency  count  of  the  various 
additional  factors  (Interview  Question  3g)  the  26 
interviewees  use  to  evaluate  user  requested  changes.  The 
total  of  the  factor  counts  (118)  is  greater  than  26  because 
some  interviewees  stated  9  or  10  different  factors. 

Besides  the  48  factors  of  Appendix  C,  the  interviewees 
may  want  to  use  other  factors  to  evaluate  user  change 
requests.  However,  one  reason  or  another  may  prevent  the 
interviewee  from  using  these  other  factors.  Interview 
Questions  31  and  3m  ask  the  interviewee  for  these  other 
factors. 

Interview  Questions  31  and  3m.  These  questions 
asked  the  interviewee  the  following:  (1)  if  other  factors, 
currently  not  in  use,  are  needed  to  evaluate  requests 
(Interview  Question  31) ;  and  (2)  what  are  these  factors 
(Interview  Question  3m) . 

The  interviewees  could  select  from  one  of  the  two 
choices  (either  yes  or  no)  in  Interview  Question  31.  Table 
4.5  presents  the  percentages  of  the  26  interviewees  who 
felt  other  factors  should  be  used  to  evaluate  user 
requested  changes. 

Table  4.5  indicates  a  low  percentage  of  the 
respondents  feel  other  factors  (besides  those  currently  in 
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Table  4 . 5 


Percentages  of 

Should 

Interviewees  Who  Feel  Other 

Be  Used  to  Evaluate  Requests 

Factors 

Response 

Count 

Percent 

Additional  factors 
used 

should  be 

6 

23 

Additional  factors 
not  be  used 

should 

20 

77 

use)  are  necessary  to  evaluate  user  requested  changes. 
Table  4.6  is  a  frequency  count  of  the  various  additional 
factors  from  the  six  interviewees  who  said  additional 
factors  should  be  used  to  evaluate  these  requests. 

From  the  lists  in  Appendix  C  and  Table  4.6,  the 
researcher  asked  the  interviewee  to  identify  those  factors 
that  changed  the  original  user  request.  Interview 
Questions  7e  and  7f  gather  data  in  this  area. 

Interview  Questions  7e  and  7f.  These  questions 
asked  if  the  interviewee  ever  revised  a  user  requested 
change  (Interview  Question  7e)  and  what  circumstances 
caused  this  revision  (Interview  Question  7f) . 


Table  4.6 


Frequency  Table  for  Other 

Be  Used  to  Evaluate 

Factors  that 

User  Requests 

Could 

Response 

Count 

Percent 

Exclude  politics 

1 

16.7 

Guidance  from  AFR  89-1 

1 

16.7 

Changing  the  Form  1391  criteria 

1 

16.7 

Verified  mission  essential  by 
MAJCOMS 

1 

16.7 

Exclude  personal  preferences 

2 

33.3 

Table  4.7  presents  the  percentages  of  the  26 
respondents  involved  with  user  requested  changes  that 
required  a  revision.  The  interviewees  could  select  from 
one  of  two  choices  (either  yes  or  no)  in  Interview  Question 
7e. 

Table  4.7  indicates  that  a  very  high  percentage  of  the 
interviewees  were  involved  with  revisions  to  the  original 
request.  Interview  Question  7f  asks  the  25  interviewees 
for  the  circumstances  that  caused  this  revision. 

Appendix  D  lists  the  24  circumstances  that  caused  the 
interviewees  to  revise  to  the  original  user  request,  and 
the  frequency  count  for  each  circumstance.  The  sum  of  the 
counts  for  all  requests  is  greater  than  25  because  some 
interviewees  stated  4  or  5  circumstances. 
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Table  4.7 


Percentages  of  Interviewees  Who  Handled 


Changes  to  the  User 

Requested  Changes 

Response 

Count 

Percent 

Have  been  involved  with 
changes  to  the  changes 

25 

96.1 

Have  not  been  involved  with 
changes  to  the  changes 

1 

3.9 

Appendix  D  indicates  that  the  three  most  frequent 
circumstances  include  the  following:  (1)  funds 
availability,  (2)  bad  information  about  the  requested 
change,  and  (3)  the  requested  change  was  not  in  the  project 
scope.  These  factors  listed  in  Appendix  D  may  require 
special  attention  when  evaluating  requested  changes. 

Chapter  V  compares  these  factors  to  the  list  from  Interview 
Question  3g. 

Interview  Questions  3i.  3i  and  3k.  These 
questions  were  designed  to  identify  the  following: 

1.  The  percentages  of  interviewees  with  factors  (from 
Interview  Questions  3g)  that  are  officially  approved 
(Interview  Question  3i) . 

2.  Who  approved  those  factors  (Interview  Question 

3j)  . 

3.  Prior  to  approval,  who  did  the  interviewee  discuss 
or  coordinate  their  factors  with  (Interview  Question  3k) . 
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The  respondents  could  select  from  one  of  two  choices 


(either  yes  or  no)  in  Interview  Question  3i.  Table  4.8 
presents  the  percentages  of  the  26  interviewees  who  state 
that  their  factors  have  been  officially  approved. 


Table  4.8 

Percentages  of  Interviewees  Whose  Evaluation  Factors 
Have  Been  Officially  Approved 


Response 

Count 

Percent 

Factors  have  not  been  officially 
approved 

17 

65.4 

Factors  have  been  approved  on 
certain  projects 

5 

19.2 

Factors  have  been  officially 
approved 

4 

15.4 

Table  4.8  indicates  that  a  low  percentage  of 
interviewees'  factors  have  been  officially  approved.  The 
next  logical  question  is  Interview  Question  3 j ,  which  asks 
those  four  interviewees  with  officially  approved  factors 
about  the  approval  of  their  factors.  Table  4.9  represents 
the  responses  of  these  four  interviewees.  Interview 
Question  3j  is  an  open-ended  question. 

The  researcher  summarized  and  grouped  these  responses 
into  the  categories  as  shown  in  Table  4.9.  The  researcher 
believes  that  there  is  not  enough  information  to  further 
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Table  4.9 


Frequency  Count  of  Approval  Authority  on  the 
Interviewee  Factors  to  Evaluate  User 
Change  Requests 


Response 

Count 

Percent 

Someone  in  the  interviewees 
chain-of -command 

3 

75.0 

Facility  change  board 

1 

25.0 

analyze  this  aspect  of  evaluating  user  requested  changes. 
Thus,  this  chapter  contains  no  analysis  to  Interview 
Question  3k  (who  did  the  interviewee  discuss  or  coordinate 
their  factors  with,  prior  to  the  approval) . 

Research  Question  2 .  Research  question  2  is  "How 
should  the  evaluation  factors  vary  in  different  stages  of 
the  design  and  construction  phases,  if  at  all?"  Interview 
Questions  4a  and  4b  address  this  research  question.  The 
responses  to  these  interview  questions  are  discussed  below. 

Interview  Question  4a.  This  question  asks  the 
interviewees  if  their  factors  to  evaluate  user  requested 
changes  differ  when  the  project  is  in  design,  at 
contracting,  or  under  construction.  Table  4.10  presents 
the  percentages  of  the  26  interviewees  whose  factors  differ 
in  the  various  stages  of  the  MILCON  process. 
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Table  4.10 


Percentages  of  Interviewees 

Requests  that  Vary  Between 

with  Factors 

the  Design, 

to  Evaluate 

Contracting 

Response 

Count 

Percent 

Factors  differ 

22 

84.6 

Factors  do  not  differ 

4 

15.4 

Table  4.10  indicates  that  most  respondents  stated 
their  evaluation  factors  differ  between  the  project  design, 
contracting,  and  construction  phases.  The  next  interview 
question  asks  the  interviewees  to  describe  these 
differences . 

Interview  Question  4b.  This  open-ended  question 
asked  those  22  who  responded  "yes”  to  Interview  Question  4a 
to  identify  those  different  factors  used  in  either  design, 
at  contracting,  or  under  construction.  Appendix  E  presents 
the  frequency  counts  of  the  various  differences.  The 
researcher  summarized  some  of  the  responses  to  allow 
tabulation  of  the  main  idea  in  a  frequency  analysis. 

Appendix  E  indicates  the  most  frequent  response  is 
that  the  project  manager  has  more  flexibility  to 
accommodate  changes  in  design  (because  of  less  costs 
involved)  versus  contracting  or  construction  phases.  The 
next  most  frequent  response  is  that  while  the  project  is  at 
contracting,  a  key  concern  is  to  balance  the  request  with 
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awarding  the  project  in  the  current  fiscal  year.  The 
researcher  grouped  the  responses  into  12  different  items. 
The  total  of  the  responses  is  greater  than  22  because  some 
interviewees  provided  2  or  3  responses. 

A  comparison  of  Appendix  E  to  Appendix  C  reveals  that 
not  one  of  the  interviewees  responded  with  a  "varies  based 
on  the  project  phase"  factor  to  Interview  Question  3g  (the 
factors  used  to  evaluate  the  requests) .  Perhaps  the 
interviewees  felt  this  factor  was  to  broad  a  response  for 
Interview  Question  3g. 

Research  Question  3.  Research  question  3  is  "How 
should  the  factors  be  weighed  to  evaluate  user  requested 
changes?"  Interview  Questions  5a  and  5b  address  this 
research  question.  The  responses  to  these  interview 
questions  are  discussed  below. 

Interview  Question  5a.  This  structured  question 
asks  the  interviewee  to  rate  their  responses  from  Interview 
Question  3g.  Interview  Question  5a  asks  the  interviewee 
about  the  importance  of  each  evaluation  factor  when 
evaluating  a  user  change  request.  The  interviewee  could 
select  from  one  of  three  following  choices:  (1)  the 
specific  factor  is  either  important,  (2)  moderately 
important,  or  (3)  not-to-important .  Appendix  C  presents 
the  frequency  counts  of  the  three  choices  for  each  factor. 

The  26  interviewees  selected  choices  for  116  of  the 
total  of  118  factors  from  Interview  Question  3g.  The 
difference  is  because  an  interviewee  responded  "varies"  for 
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two  factors,  which  could  not  be  grouped  into  any  of  the 
three  choices.  Table  4.11  summarizes  the  frequency  counts 
of  the  three  choices. 


Table  4.11 

Frequency  Count  of  Individual  Factors  Versus 
Importance  of  that  Factor 


Response 

Count 

Percent 

The  factor  is  important 

87 

75.0 

The  factor  is  moderately 
important 

25 

21.6 

The  factor  is  not-too- 
important 

4 

3.4 

Appendix  C  indicates  the  interviewees  feel  most  of 
their  factors  are  important.  Fourteen  of  the  48  factors  in 
Appendix  C  are  used  by  three  or  more  respondents.  For  only 
one  (life  cycle  cost  or  economic  analysis)  of  these  14 
factors  did  the  interviewees  more  frequently  select 
responses  in  either  the  "moderately  important"  or  "not-too- 
important  categories."  For  the  remaining  13  factors,  the 
majority  of  interviewees  selected  the  "important  to  know" 
response. 

Interview  Question  5b.  This  structured  question 
uses  the  interviewee  factor  responses  from  Interview 
Question  3g.  The  question  asks  the  interviewee  about  the 
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degree  of  difficulty  to  obtain  an  answer  to  each  factor. 

The  interviewee  could  select  from  one  of  three  following 
choices:  (1)  the  specific  factor  is  either  easy,  (2) 

moderately  difficult,  or  (3)  difficult.  Appendix  C 
presents  the  frequency  counts  of  the  three  choices  for  each 
factor. 

The  26  respondents  selected  choices  for  116  of  the 
total  of  118  factors  from  Interview  Question  3g.  The 
difference  is  because  an  interviewee  responded  "varies”  for 
two  factors,  which  could  not  be  grouped  into  any  of  the 
three  choices.  Table  4.12  summarizes  the  frequency  counts 
of  the  three  choices. 


Table  4.12 

Frequency  Count  of  Individual  Factors  Versus  Degree 
of  Difficulty  of  that  Factor 


Response 

Count 

Percent 

The  factor  is  easy  to  answer 

58 

50.0 

The  factor  is  moderately 
difficult  to  answer 

38 

32.8 

The  factor  is  difficult  to 
answer 

20 

17.2 

Table  4 . 12  shows  the  responses  are  more  evenly 
distributed  than  from  Table  4.11.  The  interviewee 
responses  indicated  that  for  approximately  half  of  the 
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factors,  the  interviewees  felt  that  factor  is  easy  to 
answer. 

For  6  of  the  14  factors  with  three  or  more 
respondents,  a  majority  stated  that  it  would  be  easy  to 
obtain  an  answer  to  that  factor.  These  factors  include  the 
following;  (1)  funds  availability,  (2)  is  change  in  scope 
(legal) ,  (3)  MAJCOM  opinions,  (4)  benefits  to  the  Air  Force 
or  government,  (5)  identifying  if  the  change  makes  the 
facility  "complete  and  usable",  and  (6)  a  technical 
evaluation  of  the  change.  For  3  of  the  14  factors  with 
three  or  more  respondents,  a  majority  stated  that  it  would 
be  moderately  difficult  to  obtain  an  answer  to  that  factor. 
These  factors  include  the  following;  (1)  is  the  request  a 
want  or  need,  (2)  schedule  impact,  and  (3)  cost 
determination  of  the  request.  For  2  of  the  14  factors  with 
three  or  more  respondents,  a  majority  stated  that  it  would 
be  difficult  to  obtain  an  answer  to  that  factor.  These 
factors  include  the  following;  (1)  is  the  change  valid, 
and  (2)  a  functional  benefit  to  the  user.  The  remaining  3 
of  the  14  factors  shows  a  tie  between  the  easy  and 
moderately  difficult  responses  ((1)  determining  the  impact 
to  mission  or  mission  essentiality) ;  or  a  tie  between  the 
easy,  moderately  difficult  and  difficult  responses  ((2) 
life  cycle  costs,  and  (3)  are  other  options  available) . 

Research  Question  4.  Research  question  4  is  "What 
formal  procedures  should  the  project  manager  follow  to 
process  the  change  request?"  Interview  Questions  6a,  6b, 
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6c,  6d,  6e,  and  6f  of  the  questionnaire  address  this 
research  question.  The  responses  to  these  interview 
questions  are  discussed  below. 


Interview  Questions  6a  and  6b.  These  questions 
ask  the  interviewees  if  they  work  on  projects  that  require 
formal  approval  on  UL.er  requested  changes  (Interview 
Question  6a)  and  for  a  description  of  this  formal  approval 
process  (Interview  Question  6b) . 

The  respondents  could  select  from  one  of  two  choices 
(either  yes  or  no)  in  Interview  Question  6a.  Table  4.13 
presents  the  percentages  of  the  interviewees  who  stated 
that  the  requested  change  requires  formal  approval. 

Table  4.13  indicates  that  most  respondents  work  on 
projects  that  require  formal  approval.  Open-ended 
Interview  Question  6b  asks  the  interviewee  to  describe  this 
formal  approval  process. 

Table  4.13 

Percentages  of  Interviewees  that  Work  with  Changes 
that  Require  Formal  Approval 


Response 

Count 

Percent 

Requests  require 

formal 

approval 

22 

85.6 

Requests  do  not 
approval 

require 

formal 

2 

7.7 

Request  approval 
situation 

depends 

on 

2 

7.7 
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Appendix  F  presents  a  frequency  count  of  the  various 
formal  approval  processes.  These  responses  are  from  the  24 
interviewees  who  work  with  requests  that  either  require 
formal  approval,  or  the  situation  dictates  that  the 
requests  require  formal  approval. 

Appendix  F  indicates  that  the  most  frequent  response 
is  the  basic  approval  process  includes  the  user  forwarding 
the  request  to  the  base;  once  approved,  the  request  is  sent 
to  the  MAJCOM;  and  if  approved,  the  request  is  then  sent  to 
the  AFRCE.  One  reason  for  the  most  frequent  response  is 
the  current  version  of  AFR  89-1  states  "The  requiring 
MAJCOM  validates  and  approves  user  change  requests.  ..." 
(11:9).  Although  AFR  89-1  also  allows  the  MAJCOMs  to 
delegate  some  or  all  user  change  request  authority.  Three 
of  the  interviewees  identified  this  delegation  process. 

The  next  most  frequently  identified  approval  process  is  to 
discuss  the  requested  change  at  regularly  held  meetings 
with  all  the  project  players  present.  One  of  the 
interviewees  responded  that  the  most  effective  meetings  are 
run  by  a  senior  officer  from  an  office  that  develops 
project  requirements,  and  has  close  ties  with  the 
installation  wing  commander. 

The  next  step  of  the  research  was  to  determine  if  any 
documents  exist  that  describe  this  formal  process. 

Interview  Questions  6c  and  6d  address  this  area. 

Interview  Questions  6c  and  6d.  These  questions 
ask  the  24  respondents,  whose  evaluation  procedures  include 
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formal  approval  on  requested  changes,  if  a  document  exists 
that  describes  this  process  (Interview  Question  6c)  and  to 
describe  this  document  (Interview  Question  6d) . 

The  interviewees  could  select  from  one  of  two  choices 
(either  yes  or  no)  in  Interview  Question  6c.  Table  4.14 
presents  the  percentages  of  the  24  interviewees  who  said  a 
document  describes  a  formal  approval  process. 

Table  4.14  indicates  that  most  interviewees  work  with 
changes  that  require  formal  approval,  as  spelled  out  in  a 
document.  The  next  logical  question  is  to  identify  this 
document . 


Table  4.14 

Percentages  of  Interviewees  Using  Formal  Approval 
Processes  Described  in  a  Document 


Response  Count  Percent 

A  written  document  exists  19  79.2 

A  written  does  not  exist  5  20.8 


Table  4.15  presents  the  responses  by  the  19 
interviewees,  who  work  with  requests  require  formal 
approval,  to  the  open-ended  Interview  Question  6d.  This 
table  shows  the  frequency  count  of  the  various  documents 
that  describe  .he  formal  approval  process. 


69 


Table  4.15  indicates  that  the  most  frequent  response, 
as  mentioned  by  two-thirds  of  the  interviewees,  is  either 
individual  project  management  plans  or  AFR  89-1.  The  sum 
of  the  counts  is  greater  than  19  because  some  interviewees 
provided  2  responses. 

The  next  item  of  the  research  is  to  determine  the 
similarities  and  differences  of  these  policies. 

Table  4.15 

Frequency  Count  of  the  Written  Documents  that  Establish 
the  Formal  Written  Approval  Process 


Response  Count  Percent 


Individual  project  management 

plans  9  37.5 

AFR  89-1  7  29.2 

Project  managers  handbook  3  12.5 

Could  not  recall  specific  plan  5  20.8 

Operating  Instructions  1  4.2 


Interview  Questions  6e  and  6f.  These  questions 
ask  the  interviewee  if  the  approval  policies  differ  on 
different  projects  (Interview  Question  6e)  and  what  are 
these  differences  (Interview  Question  6f)  . 

Table  4.16  presents  the  percentages  of  the  26 
respondents  who  identify  that  approval  policies  differ  on 
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different  projects.  The  interviewees  could  select  from  one 
of  two  responses,  either  '•yes'*  or  "no". 

Table  4.16  shows  no  majority  exists,  among  the 
respondents,  on  whether  approval  policies  differ  on 
different  projects. 

Table  4.16 

Percentages  of  Interviewees  Who  Identify  that 
User  Requested  Change  Approval  Policies 
Differ  on  Different  Projects 


Response 

Count 

Percent 

Approval  policies  do  not  vary 

based  on  project 

13 

50.0 

Approval  policies  do  vary  based 

on  project 

13 

50.0 

Table  4.17  presents  a  frequency  count  of  these 
differences  in  approval  policies  of  the  13  respondents  who 
answered  "yes”  to  Interview  Question  6e.  Table  4.17 
indicates  the  most  frequent  response  is  that  the  approval 
policy  depends  on  who  the  user  is  and  who  is  driving  the 
request. 

Research  Question  5.  Research  question  5  is  "What 
types  of  organizations  should  the  user  change  request  be 
coordinated  with?"  Interview  Questions  7a,  7b,  7c,  and  7d 
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address  this  research  question.  The  responses  to  these 
interview  questions  are  provided  below. 


Table  4.17 

Frequency  Count  of  Differences  in  Approvals 
of  User  Requested  Changes 


Response 

Count 

Percent 

Who  user  is  and  who  is  driving 
request 

4 

30.8 

Varies  based  on  project 

3 

23 . 1 

Cost  of  change  determines 
approval  authority 

3 

23 . 1 

Differences  spelled  out  in 
management  plan 

3 

23 . 1 

Interview  Questions  7a 

.  7b  and  7c. 

These 

questions  accomplish  the  following; 

1.  Identify  the  percentage  of  interviewees  who  state 
that  requested  changes  are  coordinated  with  third  agencies 
(Interview  Question  7a) . 

2.  Report  the  percentage  of  interviewees  who  state 
coordination  is  obtained  from  all  agencies  involved  with 
the  project  (Interview  Question  7b). 

3.  Identify  what  agencies  are  typically  coordinated 
with  (Interview  Question  7c) . 

The  respondent  could  select  from  one  of  two  choices 
(either  yes  or  no)  in  Interview  Question  7a.  All  of  the  26 
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interviewees  said  "yes”  that  the  user  requested  change  is 
coordinated  with  third  organizations.  A  very  high 
percentage  is  expected  to  respond  "yes"  because  AFR  89-1 
emphasizes  the  coordination  process  (11:16). 

The  interviewees  could  select  from  one  of  two  choices 
(either  yes  or  no)  in  Interview  Question  7b.  Table  4.18 
presents  the  percentages  of  the  26  interviewees  who  stated 
that  the  changes  are  coordinated  with  all  agencies  involved 
with  the  project. 


Table  4.18 

Percentages  of  Interviewees  Who  Work  on  Projects  Where 
Requested  Changes  Are  Coordinated  with  All  Agencies 
Involved  with  the  Project 


Response 

Count 

Percent 

For  each  request  coordination  is 
obtained  from  all  agencies 

17 

68.0 

For  each  request  coordination  is 
not  obtained  from  all  agencies 

8 

32 . 0 

A  few  of  the  interviewees  pointed  out  that  they 
assumed  "all  agencies  involved"  to  mean  "all  applicable 
agencies."  This  was  a  correct  assumption.  Two  of  the 
interviewees  also  stated  that  all  agencies  were  at  least 
notified  of  the  request,  and  the  agencies'  responsibility 
included  notifying  Civil  Engineering  of  any  impacts  on 
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their  organization.  The  researcher  included  these 
responses  in  the  category  of  "coordination  is  obtained  from 
all  agencies.” 

Table  4.19  presents  a  frequency  count  of  the  agencies 
that  are  typically  coordinated  with.  The  researcher 
summarized  and  grouped  the  interview  responses  into  the 
categories  shown  in  Table  4.19.  The  interviewees  who 
resDonded  "no”  to  Interview  Question  7b  provided  responses 
in  Table  4.19.  Although  some  of  the  interviewees  who 
responded  "coordination  is  obtained  from  agencies"  answered 

Table  4.19 

Frequency  Count  of  the  Agencies  Typically 
Coordinated  with  on  a  Requested  Change 


Response  Count 

Design  and  construction  agent  2 

Agencies  that  have  a  need  to  know  5 

Base  level  organizations  (outside 

civil  engineering)  7 

Organizations  within  base  civil  engineering  3 

Organizations  within  the  MAJCOM  2 


Interview  Question  7b  anyway.  The  researcher  believes  that 
confusion  existed  among  some  respondents  over  the  general 
set-up  of  this  group  of  interview  questions. 
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Table  4 . 19  indicates  the  most  frequent  response  is 
coordination  of  the  user  requested  chanqe  is  with  base 
level  agencies  outside  civil  engineering.  This  is  what  can 
be  expected  because  most  of  the  organizations  impacted  by  a 
change  request  are  on  the  installation. 

The  next  logical  question  is  to  ask  how  is  this 
coordination  obtained  from  the  agencies  involved  with  the 
project.  Interview  Question  7d  addresses  this  area. 

Interview  Question  7d.  This  open-ended  question 
asked  the  interviewee  how  they  coordinate  the  request  with 
other  agencies. 

Table  4.20  presents  a  frequency  count  of  the  various 
coordination  methods  as  stated  by  the  26  respondents. 

Table  4.20 

Frequency  Count  of  the  Various  Methods  to  Obtain 
Coordination  from  Outside  Organizations 


Response 

Count 

Percent 

Discussion  over  the  phone 

11 

42 . 3 

In  writing 

11 

42.3 

At  meetings 

4 

15 . 4 

Organizations  sign  off  on 
form  letter 

3 

11.5 

Phone  calls,  followed  up 
by  a  letter 

2 

7.7 

Others  do  coordination 


2 


7.7 


Table  4.20  indicates  the  two  most  frequent  responses  are 
that  the  interviewees  obtain  coordination  by  either  the 
phone  or  in  writing.  The  sum  of  the  counts  for  all 
responses  is  greater  than  26  because  some  interviewees 
provided  2  responses. 

Research  Question  6.  Research  question  6  is  "Do  any 
existing  decision  support  systems  address  how  to  evaluate 
requested  changes?"  Interview  Question  3h  addresses  this 
research  question.  The  responses  to  this  open-ended 
interview  question  is  provided  below. 

Interview  Question  3h.  This  question  asked  the 
26  respondents  about  the  organization  of  their  factors 
(from  Interview  Question  3g) .  Table  4.21  presents  the 
frequency  count  associated  with  each  response. 


Table  4.21 

Frequency  Count  of  Various  Methods  to  Organize  the 
Factors  Used  to  Evaluate  User  Requested  Changes 


Response 

Count 

Percent 

No  formal  organization 

19 

73 . 1 

Personal  i'  aitive  process 

3 

11.5 

Project  books 

2 

7.7 

Situation  dictates 

1 

3.8 

Operating  instruction 

1 

3.8 
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Table  4.21  indicates  that  the  vast  majority  of 
interviewees  (with  responses  of  "no  formal  organization"  or 
"personal  intuitive  process")  do  not  have  their  factors 
organized  in  a  decision  support  system  (e.g.,  checklist  or 
flowchart) .  A  few  of  the  interviewees  stated  that  the 
process  to  evaluate  user  requested  changes  does  not  lend 
itself  to  a  checklist  that  could  cover  all  situations.  The 
researcher  pointed  out  that  developing  a  checklist  to  cover 
all  situations  is  not  necessarily  a  goal  of  this  research. 

Chapter  Summary 

Through  the  use  of  tables,  this  chapter  presents  the 
percentages  and  frequency  counts  of  the  interviewee 
responses.  This  chapter  also  grouped  all  interview 
questions  with  the  corresponding  research  question. 

Most  of  this  chapter's  results  address  the  first 
research  question.  This  effort  shows  the  factors  the 
interviewees  use  to  evaluate  user  requested  changes.  Most 
of  these  factors  are  gained  through  individual  experience, 
and  not  from  a  regulation.  Also,  most  interviewees  were 
involved  with  revisions  to  the  original  change  requests. 

Other  tables  in  this  chapter  identify  that  most 
interviewee  factors  differ  in  different  phases  of  the 
project,  and  address  the  formal  approval  process  of  the 
user  change  request.  Most  interviewees  stated  that  a 
written  document  exists  to  identify  that  formal  approval 
process.  About  half  on  the  interviewees  stated  that  the 
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approval  policies  on  user  requested  changes  varies  by 
project. 

Next  Chapter  of  Thesis 

Chapter  V  (Analysis  and  Discussion)  analyzes  the 
research  data  from  the  summary  tables  and  appendices. 
Various  tables  are  compared  and  contrasted  to  form  the 
basis  for  the  conclusions  and  recommendations  developed  in 
Chapter  VI  (Summary  and  Recommendations) . 
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This  chapter  is  divided  into  two  sections.  The  first 
section  discusses  the  completed  and  remaining  stages  of  the 
"reason  analysis ”  methodology  in  this  research.  The  second 
section  analyzes  the  interview  data  to  address  each  of  the 
research  questions  from  Chapter  I. 

Employing  the  Reason  Analysis 

As  stated  in  Chapter  III,  the  reason  analysis  consists 
of  five  stages.  The  first  stage  of  this  research  created 
the  six  research  questions  posed  in  Chapter  I.  The  second 
stage  allowed  the  researcher  to  gain  some  insight  into 
understanding  how  user  change  requests  should  be  evaluated 
by  conducting  the  literature  review  in  Chapter  II.  Time 
limitations  forced  the  researcher  to  combine  a  large  part 
of  the  second  stage  with  the  third  stage  (development  of 
the  accounting  scheme) .  The  questionnaire  in  Appendix  A 
represents  the  accounting  scheme  to  address  effective 
decision-making  procedures  on  user  requested  changes.  The 
fourth  stage  is  conducting  the  interviews.  The  results  are 
in  Appendix  B.  The  fifth  and  final  stage  is  the  counting 
and  summarizing  to  assess  cause  and  meaning  of  actions. 
Chapter  IV  provides  the  initial  summaries  of  data. 

However,  Zeisel  states  that  "By  relating  the  answers  in  one 
dimension  to  those  from  another  dimension,  new  insights  can 
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be  gained”  (39:183).  The  remaining  portion  of  this  chapter 
relates  the  responses  of  different  questions  to  look  for 
new  insights  to  address  the  research  questions. 

Research  Questions  1  and  3 

Research  question  1  is  "What  factors  should  be  used  to 
evaluate  change  requests?”  Research  question  3  is  "How 
should  these  factors  be  weighed  to  evaluate  user  requested 
changes?"  Research  question  3  closely  follows  research 
question  1,  therefore  these  questions  are  grouped  in  a 
single  discussion. 

The  first  place  to  look  for  policy  and  guidance  is  in 
the  regulations.  Table  4.4  indicates  the  current  version 
of  the  APR  89-1  provides  little  or  no  guidance  to  the 
interviewees.  Also,  Table  4.3  indicates  that  most  of  the 
interviewees  stated  that  they  could  not  recall  the  guidance 
they  followed  from  the  previous  version  of  APR  89-1.  Hence 
the  need  to  ask  the  project  managers  for  their  factors 
gained  from  experience  in  evaluating  requests. 

Appendix  C  lists  the  48  factors  that  the  interviewees 
use  to  evaluate  requested  changes.  This  list  is  much 
larger  than  the  evaluation  factors  provided  in  either  the 
previous  or  current  version  of  APR  89-1. 

Appendix  C  indicates  the  five  interviewee  factors  used 
most  often  include  the  following:  (1)  the  cost  of  the 
request,  (2)  the  schedule  impact,  (3)  the  funds 
availability,  (4)  determining  if  the  request  is  a  want  or 
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need,  and  (5)  determining  the  impact  to  the  mission. 

Either  or  both  versions  of  APR  89-1  identify  the  factors 
with  the  five  highest  frequency  counts.  The  previous  and 
current  versions  of  APR  89-1  state  to  consider  funds 
availability  when  evaluating  a  request.  The  previous 
version  of  APR  89-1  states  to  examine  the  schedule  impact 
before  implementing  a  requested  change.  Both  versions  of 
APR  89-1  include  the  factors  "is  the  request  a  want  or 
need”  and  "impact  to  the  mission  or  mission  essential.” 

Table  4.5  leads  the  researcher  to  believe  most 
interviewees  currently  use  the  factors  that  are  necessary 
to  evaluate  the  requested  changes.  Project  managers  then 
operate  with  the  flexibility  and  freedom  to  evaluate  the 
requests.  No  particular  individual  or  organization  would 
tell  a  project  manager  to  "overlook"  certain  factors  when 
evaluating  a  request.  However,  most  of  the  other  factors 
in  Table  4.6  (e.g.,  exclude  politics,  exclude  personal 
preference,  and  changing  the  Porm  1391  criteria)  are  very 
difficult  to  exclude  or  include  as  factors.  Then  the  list 
of  Appendix  C  contains  the  most  "practical"  factors  to 
evaluate  user  requested  changes. 

The  researcher  divided  the  48  factors  of  Appendix  C 
into  the  following  three  classifications:  (1)  attributes, 
(2)  influences,  and  (3)  predispositions.  As  stated  in 
"Questionnaire  Drafting"  Seccion  of  Chapter  III,  these 
three  classifications  represent  the  reasons  why  people  do 
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things  the  way  they  do.  This  is  important  in  the  "art  of 
asking  why . " 

Appendix  G  presents  the  factors  grouped  into  one  of 
the  three  classifications.  Most  of  the  48  factors  fall 
into  the  attribute  classification  (20  total  count)  or 
influence  classification  (21  total  count) .  The  remaining 
seven  factors  fall  into  the  predispositions  classification. 
This  indicates  that  upon  receiving  a  requested  change,  a 
project  manager  would  think  more  often  about  the 
"attributes"  of  the  request  and  "influences"  upon  the 
individual  rather  than  their  "predispositions." 

Also,  Appendix  G  divides  the  "attributes"  and 
"influences"  into  factors  associated  with  either  the 
"quality  of  the  facility"  or  "execution  of  the  project." 
Some  factors  could  not  be  grouped  into  the  either  "quality" 
or  "execution"  categories.  The  researcher  refers  to  these 
as  "others"  in  Appendix  G.  The  "others"  category  typically 
refers  to  opinions  of  various  agencies  or  individuals. 

Table  G.l  shows  that  the  "execution"  and  "quality" 
frequency  response  counts  are  nearly  equal  (36  versus  32) , 
in  the  "attribute"  classification.  However,  in  the 
"influence"  classification  the  execution  factors  outnumber 
the  quality  factors  (19  to  10) .  This  indicates  that 
external  sources  influence  project  managers  more  towards 
the  project  execution  concerns  rather  than  the  quality  of 
the  facility  when  evaluating  a  request. 
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Table  G.l  also  contains  the  "Count  and  Importance 
Degree"  score  for  each  factor.  The  "Count  and  Importance 
Degree"  is  obtained  by  multiplying  the  frequency  of  each 
response  by  the  importance  factor  of  that  response  (an 
"important"  response  is  worth  three  points,  a  "moderately 
important"  response  is  worth  two  points,  and  a  "not-too- 
important"  response  is  worth  one  point) .  Higher  scores 
represent  factors  used  more  often  and  rated  more  important 
by  the  interviewee. 

Appendix  G  indicates  that  a  factor  with  a  "High 
Frequency  Response  Count"  also  has  a  high  importance  score. 
The  "cost  of  request"  factor,  with  the  "Highest  Frequency 
Count,"  had  the  highest  "Count  and  Importance  Degree" 
score.  The  next  four  highest  "Frequency  Response  Count" 
factors  (schedule  impact,  funds  availability,  impact  to  the 
mission  or  mission  essential,  and  is  the  request  a  want  or 
need)  ?;lso  received  the  next  four  highest  "Count  and 
Importance  Degree"  scores.  This  would  be  normally  expected 
since  the  more  the  project  manager  uses  a  factor,  the  more 
importance  would  be  placed  on  that  factor. 

To  determine  the  degree  of  linear  association  between 
the  "Frequency  Response  Count"  and  "Count  and  Importance 
Degree,"  the  researcher  entered  these  scores  into  the 
Simple  Correlation  subprogram  of  the  Statistix 
microcomputer  analysis  program.  The  results  are  in 
Appendix  H.  From  Appendix  H,  "Count"  represents  the 
"Frequency  Response  Count"  score,  and  "Import"  represents 
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the  "Count  and  Importance  Degree"  score.  The  Statist ix 
computed  correlation  coefficient  was  .9889.  This  indicates 
a  strong  positive  linear  relationship  between  "Frequency 
Response  Count"  and  "Count  and  Importance  Degree"  scores. 
This  correlation  score  leads  the  researcher  to  conclude 
that  the  more  the  particular  factor  is  used,  the  more 
importance  the  project  manager  places  with  that  factor. 

Each  factor  also  has  a  corresponding  "Weighted 
Difficulty  Average"  value.  The  "Weighted  Difficulty 
Average"  is  obtained  by  averaging  the  degree  of  difficulty 
scores  for  each  response  (an  "easy"  response  is  worth  one 
point,  a  "moderately  difficult"  response  is  worth  two 
points,  a  "difficult"  response  is  worth  three  points) . 
Higher  scores  represent  an  increased  difficulty  to  address 
that  particular  factor.  All  scores  range  between  the 
values  of  one  and  three. 

To  determine  the  degree  of  linear  association  between 
the  "Frequency  Response  Count"  and  "Weighted  Difficulty 
Average,"  the  researcher  entered  these  scores  into  the 
Simple  Correlation  subprogram  of  the  Statistix 
microcomputer  analysis  program.  The  results  are  in 
Appendix  H.  From  Appendix  H,  "Count"  represents  the 
"Frequency  Response  Count"  score,  and  "Diff"  represents  the 
"Weighted  Difficulty  Average"  score.  The  Statistix 
computed  correlation  coefficient  was  negative  .0203.  This 
indicates  strong  evidence  of  the  lack  of  a  linear 
relationship  between  "Frequency  Response  Count"  and 
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"Weighted  Difficulty  Average"  scores.  This  correlation 
score  leads  the  researcher  to  conclude  that  the  degree  of 
difficulty  of  an  evaluation  factor  has  little  bearing  on  a 
project  manager's  use  of  that  factor. 

The  research  also  compares  the  reasons  to  revise  the 
original  change  (Appendix  D)  to  the  list  of  factors  in 
Appendix  C.  Eight  factors  appear  on  both  lists.  These 
factors  include  the  following:  (1)  constructability,  (2) 
maintenance  of  real  property,  (3)  is  the  request  legal,  (4) 
how  urgent  is  the  request,  (5)  impact  to  the  mission  or 
mission  essential,  (6)  funds  availability,  (7)  technical 
evaluation,  and  (8)  a  great  idea  at  the  wrong  time. 

Project  managers  should  be  aware  of  these  evaluation 
factors  (particularly  of  the  "funds  availability"  and  "is 
the  request  in  scope  or  legal"  factors  because  of  their 
high  frequency  counts)  because  they  could  revise  the 
original  requested  change. 

Sixteen  of  the  24  circumstances  listed  in  Appendix  D 
do  not  appear  in  Appendix  C.  At  first  glance,  one  could 
believe  the  list  in  Appendix  C  is  not  complete  since  these 
circumstances  in  Appendix  D  influenced  the  requested 
change.  However,  these  16  circumstances  could  help  explain 
the  reason  for  the  requested  change.  (Further  study  must 
confirm  this).  Table  I.l  of  Appendix  I  divides  these  16 
circumstances  into  the  following  three  classifications: 

(1)  early  indicators  of  future  requests,  (2) 
misunderstandings,  and  (3)  poor  staff  work. 
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Project  managers  would  benefit  if  they  understood 
these  circumstances  could  become  traps  during  the 
conceptual  design  phase.  If  misunderstandings  and  poor 
staff  work  occurs  during  the  conceptual  design  phase,  then 
probably  the  project  manager  will  evaluate  more  than  a 
'•fair  share"  (from  information  that  no  one  has  control 
over)  of  user  requests  in  the  final  project  design  and 
construction  project  phases. 

From  Table  4.8,  most  interviewees '  factors  have  no 
official  approval  by  anyone  or  any  organization.  This 
leads  the  researcher  to  believe  the  project  manager 
acquires  factors  through  experience.  This  probably 
contributes  to  the  Air  Force  project  execution  problems  if 
inexperienced  personnel  manage  the  project.  Appendix  I 
could  help  these  inexperience  personnel  quickly  gain  the 
experience  of  others. 

Research  Question  2 

Research  question  2  is  "How  should  the  evaluation 
factors  vary  in  different  stages  of  the  design  and 
construction  phases,  if  at  all?" 

From  Table  4.10,  most  of  the  interviewees  stated  that 
their  evaluation  factors  vary  between  the  project  design, 
contracting,  and  construction  phases. 

From  Appendix  E,  the  most  frequent  response  was  that 
the  project  manager  has  more  flexibility  to  accommodate  the 
change  in  design  versus  when  the  project  is  at  contracting 
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or  under  construction.  Some  of  the  interviewees  summarized 
the  process  by  stating  that  during  design  the  project 
manager  considers  just  milestone  impacts;  however,  in 
construction,  the  project  manager  must  consider  both 
milestone  and  cost  impacts.  This  response  indicates  that 
the  project  manager's  predispositions  towards  the  request 
do  not  change.  For  the  later  project  phases,  the  project 
managers'  external  environment  increasingly  dictates  the 
change  approval  process.  The  project  manager  has  little 
control  over  this  operating  environment. 

To  address  research  question  2,  the  project  managers' 
evaluation  factors  remain  the  same  in  the  different  project 
phases.  Only  the  external  operating  environment  increases 
the  difficulty  of  incorporating  a  requested  change  in  the 
later  project  phases.  A  project  manager  must  increase  the 
scrutiny  the  later  the  user  submits  the  request. 

One  interviewee  stated  the  smart  project  manager 
expecting  future  requests  in  the  later  phases  of  the 
project  will  build  flexibility  into  the  early  stages  (e.g. 
design)  and  not  cut  costs  to  the  minimum,  if  possible. 

This  represents  one  way  the  project  manager  could  increase 
the  flexibility  of  their  operating  environment. 

Research  Questions  4  and  5 

Research  question  4  is  "What  formal  procedures  should 
the  project  manager  follow  to  process  the  change  request?" 
Research  question  5  is  "What  types  of  organizations  should 
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the  user  request  be  coordinated  with?”  Research  question  5 
closely  follows  research  question  4,  therefore  these 
questions  are  grouped  into  a  single  discussion. 

Table  4.15  and  Appendix  F  show  that  for  a  majority  of 
the  interviewees,  the  formal  approval  process  on  requested 
changes  follows  the  guidance  in  AFR  89-1,  either  directly 
or  indirectly  by  a  project  management  plan.  The  literature 
review  in  Chapter  II  provides  some  examples  of  management 
plans  that  address  how  to  evaluate  user  requested  changes. 
These  plans  typically  address  evaluation  of  requests  on  a 
single  page. 

Table  4.15  shows  that  a  substantial  number  (five)  of 
interviewees  could  not  recall  the  specific  plan  that 
describes  the  formal  written  approval  process.  An  initial 
impression  is  that  if  an  individual  does  not  even  know  the 
name  of  a  plan,  then  how  could  that  individual  know  about 
the  contents  of  the  plan.  However,  without  further 
questioning,  a  conclusion  cannot  be  developed.  The 
interviewee  may  not  have  worked  with  the  plan  for  a  few 
years . 

The  researcher  compared  Table  4.15  to  Table  4.4  (where 
five  of  the  interviewees  stated  that  AFR  89-1  provides  a 
large  or  fair  amount  of  their  guidance) .  None  of  these 
five  interviewees  said  that  they  follow  the  AFR  89-1 
approval  process  on  requested  changes.  Although,  these 
interviewees  may  have  been  thinking  of  other  factors  as  to 
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why  AFR  89-1  provides  a  large  or  fair  amount  of  their 
guidance. 

The  formal  approval  process  also  includes  the 
coordination  of  a  change  request.  All  interviewees 
responded  that  the  change  requests  are  coordinated  with 
organizations  other  than  the  one  requesting  the  change. 

The  purpose  of  this  interview  question  was  to  determine  how 
much  coordination  is  sufficient.  From  Table  4.18,  most  of 
the  interviewees  will  obtain  coordination  from  all  agencies 
involved  with  the  project.  From  Table  4.20,  the  most 
popular  methods  of  coordination  are  by  the  telephone  and  by 
correspondence . 

From  Table  4.19,  if  the  project  manager  does  not 
coordinate  with  all  agencies,  then  ones  most  likely 
coordinated  with  are  the  installation  agencies  outside  of 
base  civil  engineering.  This  sounds  reasonable  because 
most  agencies  impacted  by  a  requested  change  would  be  on 
the  installation.  The  researcher  could  not  find  a 
consistent  relationship  between  projects  where  each  request 
is  not  coordinated  with  all  agencies  (Table  4.18)  to  the 
method  of  coordination  (Table  4.20). 

Research  Question  6 

Research  question  6  is  "Do  any  existing  decision 
support  systems  address  how  to  evaluate  requested  changes?" 

The  research  did  not  find  any  decision  support  systems 
that  address  evaluation  of  requested  changes.  Table  4.21 
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indicates  that  most  interviewees  stated  evaluating  user 
change  requests  is  an  intuitive  process  rather  than  a 
formal  process.  This  provides  evidence  that  a  limited 
amount  of  research  exists  or  is  distributed  in  this  area. 

The  lack  of  any  decision  support  system  in  use  is 
probably  bad  for  the  entire  Air  Force,  as  identified  from 
the  problems  stated  in  Chapter  I.  The  researcher  realizes 
that  extracting  knowledge  from  an  expert  is  not  easy.  To 
show  any  benefits  from  such  a  decision  support  system  would 
be  more  difficult. 

A  decision  support  system  could  provide  valuable 
assistance  to  new  project  managers  by  alerting  them  to 
thought  processes  behind  user  request  implementation 
decisions.  Such  a  system  could  also  be  of  benefit  to  Civil 
Engineering  customers  because  they  could  understand  the 
thought  processes  used  to  evaluate  their  requests.  In  lieu 
of  a  decision  support  system,  Appendix  I  is  a  model  of 
important  issues  in  user  requested  changes. 

Next  Chapter  of  Thesis 

Chapter  VI  (Summary  and  Recommendations)  presents  the 
research  results  by  addressing  the  research  objectives  in 
Chapter  I  and  provides  recommendations  for  further  study. 
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VI .  Summary  and  Recommendations 

Chapter  Overview 

This  chapter  uses  the  research  data  to  address  the 
specific  objectives  of  this  research,  which  are  the 
following: 

1.  To  identify  factors  of  effective  decision-making 
actions  on  user  change  requests. 

2.  To  arrange  these  factors  in  a  format  that  Civil 
Engineering  project  managers  can  use. 

3.  To  recommend  ways  to  implement  these  factors. 

These  conclusions  should  assist  the  decision-making  of 
design  and  construction  project  managers  on  user  requested 
changes . 

This  chapter  presents  a  brief  summary  of  the 
research's  findings  on  the  research  objectives,  identifies 
limitations  of  the  research,  and  concludes  with 
recommendations  for  further  research  in  evaluating  user 
requested  changes  to  facility  construction  projects. 

Specific  Objectives 

Below  is  a  discussion  of  the  specific  conclusions  of 
this  research  effort.  The  specific  conclusions  assume  that 
the  goal  of  this  research  is  not  based  on  the  test  of  any 
hypothesis.  Thus  these  conclusions  may  not  be 
representative  of  the  entire  population. 
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1.  Regulations  provide  little  guidance  to  project 
managers  in  the  evaluation  of  user  requested  changes.  A 
project  manager  mostly  relies  on  their  past  experience  to 
evaluate  requested  changes.  The  most  frequently  used 
factors  include  the  following:  cost  of  the  request, 
schedule  impact,  and  funds  availability.  However,  these 
factors  are  also  stated  in  AFR  89-1,  Design  and 
Construction  Management. 

2.  No  individuals  or  agencies  typically  dictate  to 
project  managers  the  factors  to  use  in  evaluating  requests. 
However,  in  later  project  phases,  factors  from  the  external 
environment  play  a  major  role  in  the  decision-making 
process. 

3.  This  research  did  not  uncover  an  effective 
decision  support  system,  in  use,  that  project  managers  use 
to  evaluate  user  change  requests.  Most  project  managers 
stated  that  arranging  the  process  in  a  checklist  would  not 
be  practical  because  of  the  wide  variety  of  circumstances 
involved  with  user  changes. 

4.  The  model,  in  Fig.  6.1,  shows  the  important  issues 
in  the  user  requested  change  process  and  serves  as  a 
starting  point  for  a  decision  support  system.  Chapter  V 
describes  the  analysis  to  obtain  the  components  in  this 
model.  Appendix  I  is  a  complete  description  of  the  model. 
This  model  incorporates  the  decision-making  factors  to 
balance  the  project  quality  and  facility  execution.  The 
two  other  important  issues  addressed  by  this  model  are  the 
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Fig.  6.1.  Proposed  User  Change  Request  Model 
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following:  (1)  the  early  indicators  of  future  requests, 

and  (2)  the  administrative  process. 

5.  Appendix  I  also  contains  the  specific  factors  with 
their  estimated  importance  and  degrees  of  difficulty  scores 
when  evaluating  a  user  requested  change.  The  research 
shows  these  factors  can  be  separated  into  the  following 
three  classifications:  (1)  attributes  of  the  request,  (2) 
influences  upon  the  individual,  and  (3)  predispositions  of 
the  individual.  The  "attributes”  and  "influences"  factors 
can  be  further  separated  into  those  associated  with  either 
the  quality  of  the  facility  or  the  execution  of  the 
project.  The  project  manager  can  then  evaluate  the 
requested  changes'  attributes,  situational  influences,  and 
individual  predispositions  to  balance  building  a  quality 
facility  (that  enhances  users'  productivity)  to  project 
execution  (within  budget  and  on-time) . 

6.  All  project  managers  should  be  able  to  organize 
their  thought  processes  in  evaluating  user  change  requests. 
This  will  enhance  the  effectiveness  of  decisions  to  build  a 
quality  facility  while  at  the  same  time  executing  the 
project  within  available  resources.  Appendix  I  is  a  guide 
to  help  project  managers  understand  thought  processes  on 
evaluating  user  requests.  This  guide  provides  the 
opportunity  for  inexperienced  project  managers  to  quickly 
gain  the  experience  of  senior  project  managers. 
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Limitations 


It  is  interesting  to  note  that  constantly  the 
interviewees  stated  that  "the  situation  dictates  the 
response.”  The  researcher  believes  that  not  all 
interviewees  could  recall  all  details  of  their  past 
experiences.  This  does  not  negate  the  results  of  this 
research,  but  should  be  considered  by  researchers 
contemplating  follow  on  work. 

Recommendations 

Specific  recommendations  for  this  research  and  future 
research  are  presented  below. 

1.  Consider  the  distribution  of  Appendix  I  (An 
Understanding  of  Important  Issues  on  Evaluating  User 
Requested  Changes)  to  design  and  construction  project 
mangers  (especially  the  lieutenants  and  new  civilians  to 
the  Air  Force) .  Also,  consider  including  Appendix  I  as 
part  of  a  project  manager's  guide.  This  appendix  presents 
the  thought  processes  behind  the  evaluation  of  a  requested 
changes.  The  project  managers  should  consider  distributing 
this  information  to  educate  users  and  customers  of  Civil 
Engineering  about  the  change  request  process. 

2.  One  recognized  limitation  of  this  research  was 
that  the  sample  only  included  Air  Force  project  managers. 
Future  research  on  requested  changes  should  include  study 
of  the  similarities  or  differences  between  the  Air  Force, 
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Appendix  A:  Interview  Questionnaire 


1.  Have  you  worked  with  users,  or  any  other  organization 
affected  by  a  construction  project,  who  submitted  changes 
to  the  design  criteria  or  who  requested  construction 
contract  modifications  in  MILCON  projects  beyond  the  35% 
design  stage  or  under  construction?  Note  that  design 
criteria  includes  user  requirements,  among  other  items  that 
the  user  may  desire. 

2.  Do  you  consider  yourself  well  qualified  in  handling 
these  agency's  requests  for  changes  in  design  criteria  or 
contract  modifications? 

3.  The  following  questions  concern  the  different  factors 
that  you  may  use  to  evaluate  changes  in:  (1)  design 
criteria  (beyond  35%  design  stage) ;  or  (2)  contract 
modifications.  Consider  the  factors  you  would  use  to 
evaluate  a  request  .  .  . 

a.  Are  you  aware  of  the  guidance  in  the  1  Nov  88 
version  of  AFR  89-1,  Design  and  Construction  Management? 

(1)  If  yes,  go  to  question  3b. 

(2)  If  no,  go  to  question  3c. 

b.  When  you  evaluate  user  requested  changes  in  design 
criteria  or  user  requests  for  contract  modifications,  how 
much  guidance  would  you  say  the  1  Nov  88  version  of  AFR  89- 
1  provides,  as  compared  to  other  sources  (including  your 
personal  intuition)?  Select  one  of  the  responses  below. 

(1)  AFR  89-1  provides  a  large  amount  of  my 
guidance. 

(2)  AFR  89-1  provides  a  fair  amount  of  my  guidance. 

(3)  AFR  89-1  provides  a  small  amount  of  my 
guidance . 

(4)  AFR  89-1  provides  none  of  my  guidance. 

c.  Were  you  aware  of  the  guidance  in  the  20  Jun  78 
version  of  AFR  89-1,  Design  and  Construction  Management? 

(1)  If  yes,  go  to  question  3d. 

(2)  If  no,  go  to  question  3f. 

d.  Did  you  follow  the  guidance  in  the  20  Jun  78 
version  of  AFR  89-1? 

(1)  If  yes,  go  to  question  3e. 

(2)  If  no,  go  to  question  3f. 
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e.  What  specific  guidance  did  you  follow  from  the  20 
Jun  78  version  of  AFR  89-1? 


f.  Do  you  use  any  other  factors  to  evaluate  user 
requests  to  change  design  criteria  or  users  requesting 
construction  contract  modifications? 

(1)  If  yes,  go  to  question  3g. 

(2)  If  no,  go  to  question  31. 

g.  Describe  the  factors  you  use  to  evaluate  these 
requests? 


h.  How  are  these  factors  organized  (in  terms  of  a 
checklist,  flowchart,  etc)? 


i.  Have  your  factors  from  above  been  officially 
approved,  in  other  words  signed  in  a  letter  or  included  as 
part  of  a  management  plan,  etc? 

(1)  If  yes,  go  to  question  3j. 

(2)  If  no,  go  to  question  31. 

j .  Who  approved  your  factors? 


k.  Prior  to  the  approval,  who  did  you  discuss  or 
coordinate  your  factors  with? 


1.  Are  there  any  factors  you  do  not  use,  but  think 
should  be  used  to  evaluate  these  requests  for  changes  in 
design  criteria  or  contract  modifications? 
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(1)  If  yes,  go  to  question  3in. 

(2)  If  no,  go  to  paragraph  4. 

m.  What  are  these  factors,  and  why  are  these  factors 
not  being  used  to  evaluate  these  requests? 


4.  The  following  questions  relate  the  user  change  request 
to  the  project  status.  Consider  the  following  two  items; 
(1)  the  factors  you  use  to  evaluate  users,  or  other 
organizations,  requesting  changes  in  design  criteria  or 
contract  modifications;  and  (2)  the  current  completion 
status  of  the  project  .  •  . 

a.  Do  your  factors  to  evaluate  these  requests  differ 
when  the  project  is  in  design,  at  contracting,  or  under 
construction? 

(1)  If  yes,  go  to  question  4b. 

(2)  If  no,  go  to  paragraph  5. 

b.  What  are  these  differences  and  how  do  they  vary 
between  the  design,  contracting,  and  construction  phases? 


5.  The  following  questions  concern  the  ranking  of  each 
specific  evaluation  factor  you  provided  above.  Consider 
categorizing  your  evaluation  factors... 

a.  How  important  is  it  to  know  the  answer  to  each  of 
your  specific  factors  when  evaluating  a  user  change 
request.  Select  from  one  of  the  categories  below. 

(1)  It  is  important  for  me  to  know  the  answer  for 
that  particular  factor. 

(2)  It  is  moderately  important  for  me  to  know  the 
answer  for  that  particular  factor. 

(3)  It  is  not-to- important  for  me  to  know  the 
answer  for  that  particular  factor. 

b.  How  difficult  is  it  to  obtain  an  answer  to  each  of 
your  specific  factors  when  evaluating  a  user  change 
request.  Select  from  one  of  the  categories  below. 

(1)  It  is  easy  to  obtain  an  answer  to  this  factor. 

(2)  It  is  moderately  difficult  to  obtain  an  answer 
to  this  factor. 
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(3)  It  is  difficult  to  obtain  an  answer  to  this 
factor. 

6.  The  following  questions  are  about  the  approval  process 
of  the  user  requested  change  in  design  criteria  or 
requested  contract  modification.  Consider  the  formal 
procedures  you  use  to  approve  or  disapprove  the  user 
request  .  .  . 


a.  Does  either  the  user  requested  change  in  design 
criteria  or  construction  modification  require  foirmal 
approval? 

(1)  If  yes,  go  to  question  6b. 

(2)  If  no,  go  to  question  6e. 

b.  Describe  the  formal  approval  process,  in  terms  of: 
(1)  who  is  involved;  (2)  what  do  they  do;  and  (3)  how  do 
they  do  it. 


c.  Is  there  a  written  document  that  establishes  that 
formal  approval  process? 

(1)  If  yes,  go  to  question  6d. 

(2)  If  no,  go  to  question  6e. 

d.  Describe  this  document (s)  and  when  was  it 
published,  in  relation  to  the  project? 


e.  Do  the  approval  policies  on  user  requests  vary  for 
different  projects? 

(1)  If  yes,  go  to  question  6f. 

(2)  If  no,  go  to  paragraph  7. 

f.  Describe  the  difference  in  the  approval  policies. 


7.  The  following  questions  concern  the  coordination  of  a 
requested  change  in  design  criteria  or  contract 
modification.  Consider  the  organizations  that  coordinate 
on  the  request  .  .  . 
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a.  Is  the  user  requested  change  in  design  criteria  or 
requested  contract  modification  coordinated  with  third 
organizations  (other  than  the  one  submitting  the  change 
request) ? 

(1)  If  yes,  to  question  7b. 

(2)  If  no,  go  to  question  7e. 

b.  For  each  request,  is  coordination  obtained  from  all 
agencies  involved  with  the  project? 

(1)  If  no,  go  to  question  7c. 

(2)  If  yes,  go  to  question  7d. 

c.  What  agencies  are  typically  coordinated  with? 


d.  How  do  you  obtain  this  coordination? 


e.  Have  you  been  in  situations  were  that  original 
request  had  to  be  revised? 

(1)  If  yes,  go  to  question  7f. 

(2)  If  no,  go  to  paragraph  8. 

f.  What  circumstances  caused  this  revision? 


g.  How  long  after  the  request  was  submitted  did  this 
revision  occur? 


8. 


THE  END  OF  INTERVIEW!!! 


Appendix  B;  Interview  Responses 


3.  The  following  questions  concern  the  different  factors 
that  you  may  use  to  evaluate  changes  in:  (1)  design 
criteria  (beyond  35%  design  stage) ;  or  (2)  contract 
modifications.  Consider  the  factors  you  would  use  to 
evaluate  a  request  .  .  . 

a.  Are  you  aware  of  the  guidance  in  the  1  Nov  88 
version  of  AFR  89-1,  Design  and  Construction  Management? 

(1)  If  yes,  go  to  question  3b. 

(2)  If  no,  go  to  question  3c. 


11  N 

12  Y 


15  N 

16  Y 


22  N 

23  Y 


27  N 


b.  When  you  evaluate  user  requested  changes  in  design 
criteria  or  user  requests  for  contract  modifications,  how 
much  guidance  would  you  say  the  1  Nov  88  version  of  AFR  89- 
1  provides,  as  compared  to  other  sources  (including  your 
personal  intuition)?  Select  one  of  the  responses  below. 

(1)  AFR  89-1  provides  a  large  amount  of  my 
guidance. 
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(2)  AFR  89-1  provides  a  fair  amount  of  my  guidance. 

(3)  AFR  89-1  provides  a  small  amount  of  my 
guidance. 

(4)  AFR  89-1  provides  none  of  my  guidance. 


1  - 

2  3 

3  - 

4  - 

5  2 

6  3 

7  4 

8  3 

9  4 

10  3 

11  - 

12  3 

13  1 

14  2 

15  - 

16  2 

17  3 

18  3 

19  3 

20  3 

21  4 

22  - 

23  3 

24  3 

25  3 

26  2 

27  - 

c.  Were  you  aware  of  the  guidance  in  the  20  Jun  78 
version  of  AFR  89-1,  Design  and  Construction  Management? 

(1)  If  yes,  go  to  question  3d. 

(2)  If  no,  go  to  question  3f. 

1  Y 

2  N 

3  N 

4  Y 

5  Y 

6  N 

7  Y 

8  Y 

9  Y 

10  N 

11  Y 

12  Y 

13  N 

14  Y 
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15  Y 

16  Y 

17  Y 

18  Y 

19  Y 

20  Y 

21  Y 

22  Y 

23  Y 

24  Y 

25  Y 

26  Y 

27  Y 

d.  Did  you  follow  the  guidance  in  the  20  Jun  78 
version  of  AFR  89-1? 

(1)  If  yes,  go  to  question  3e. 

(2)  If  no,  go  to  question  3f. 

1  Y 

2  - 

3  - 

4  Y 

5  Y 

6  - 

7  N 

8  Y 

9  N 

10  - 

11  N 

12  Y 

13  - 

14  N 

15  Y 

16  Y 

17  Y 

18  Y 

19  Y 

20  Y 

21  Y 

22  N 

23  Y 

24  N 

25  Y 

26  Y 

27  Y 

e.  What  specific  guidance  did  you  follow  from  the  20 
Jun  78  version  of  AFR  89-1? 

1  Could  not  recall  any  specific  criteria. 

2  - 
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3  - 

4  Could  not  recall  any  specific  criteria. 

5  Method  of  handling  modifications.  Funding  guidance. 
Correspondence  with  Air  Staff  and  other  agencies. 

6  - 

8  Could  not  recall  any  specific  guidance. 

9  - 

10  - 

11  - 

12  Could  not  recall  any  specific  guidance. 

13  - 

14  - 

15  Could  not  recall  any  specific  guidance. 

16  Programming  changes. 

17  Determination  if  a  change  is  mission  essential. 

18  Could  not  recall  any  specific  criteria. 

19  Cost  growth  and  scope  change  guidance. 

20  Change  order  submittal  and  approval  procedures. 

21  Justification  of  requirement.  Determination  if  a 
change  is  mission  essential. 

22  - 

23  Determination  if  change  meets  project  book  criteria. 

24  - 

25  Sections  2-3,  2-14,  4-12,  4-13. 

26  Could  not  recall  any  specific  guidance. 

27  Evaluation  of  changes  for  timely  implementation.  Look 
for  ways  to  support  or  deny  a  change  request. 

f.  Do  you  use  any  other  factors  to  evaluate  user 
requests  to  change  design  criteria  or  users  requesting 
construction  contract  modifications? 

(1)  If  yes,  go  to  question  3g. 

(2)  If  no,  go  to  question  31. 

1  Y 

2  Y 

3  N 

4  Y 

5  Y 

6  Y 

7  Y 

8  Y 

9  Y 

10  Y 

11  Y 

12  Y 

13  Y 

14  Y 

15  Y 

16  Y 

17  Y 


105 


18  Y 

19  Y 

20  Y 

21  Y 

22  Y 

23  Y 

24  Y 

25  Y 

26  Y 

27  Y 


g.  Describe  the  factors  you  use  to  evaluate  these 

requests? 

1  (1)  Is  money  available.  (2)  Common  sense.  (3)  What 
top  level  personnel  say.  (4)  Is  request  within  scope. 

(5)  Is  request  necessary.  (6)  Is  change  valid. 

2  (1)  What  does  Management  Plan  have  to  say.  (2)  Impact 
to  mission.  (3)  Benefits  to  government.  (4)  Life 
cycle  cost.  (5)  Is  money  available. 

3  - 

4  (1)  Is  request  a  want  versus  need.  (2)  Funds 

availability.  (3)  Does  user  know  what  he  wants,  look 
at  request  from  technical  viewpoint.  (4)  Timing  (e.g. 
will  change  delay  bid  opening) .  (5)  C.E.  maintenance. 

(6)  Facility  requirements  plans.  (7)  SATAF  opinions. 

(8)  HQ  SAC  opinions. 

5  (1)  Is  request  valid.  (2)  Is  request  within  project 

scope  (as  defined  in  Air  Force  criteria,  say  in  Form 
1391) .  (3)  Technical  aspects  and  if  Air  Force  guidance 

exists  (e.g.  is  a/c  authorized) . 

6  (1)  Does  request  affect  mission.  (2)  Complete  and 
usable  facility.  (3)  How  does  request  affect  quality 
of  facility.  (4)  Time  schedule.  (5)  Cost  of  change 
(6)  Design  fund  status. 

7  (1)  Command  interest.  (2)  Functional  benefit  (based  on 
either  P.M.  or  users  call).  (3)  Cost  of  request. 

8  (1)  Percent  constructed.  (2)  Funds  availability.  (3) 
Politics.  (4)  1391  objectives. 

9  (1)  Mission  impact.  (2)  PA/CWE  ratio.  (3)  Command 

funds  availability.  (4)  Schedule  impact.  (5)  Schedule 
status.  (6)  Who  submitted  request.  (7)  Long  term  use 
of  facility.  (8)  Project  type  (e.g.  aboveground  versus 
underground) .  (9)  Funding  source. 

10  (1)  Outside  comments  from  professionals.  (2)  Cost 
impacts.  (3)  Time  impacts. 

11  (1)  Time  requirements.  (2)  Is  request  valid.  (3) 

Justification  of  need  (by  using  agency  or  XB) .  (4) 

Does  design  change  have  two  letter  office  symbol 
signature.  (5)  Impact  to  schedule  and  Air  Force  need 
date. 

12  (1)  Does  request  provide  complete  and  usable  facility. 
(2)  Is  change  ’’gold  plated."  (3)  Cost  of  request. 
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13  (1)  Cost  of  request.  (2)  Affect  on  schedule.  (3)  How 
bad  does  user  need  request  versus  nice-to-have  change. 
(4)  Funds  availability. 

14  (1)  Technical  interface  requirements.  (2)  Air  Force 
need  date  and  schedule.  (3)  Cost  of  request. 

15  Will  request  make  weapons  systems  work,  or  is  request 
to  support  a  lesser  item. 

16  (1)  Does  request  provide  a  complete  and  usable 
facility.  (2)  Seeks  user  assistance  to  offset  cost  and 
scope  growth. 

17  (1)  Compare  request  against  ETLs  and  manuals.  (2) 
Compare  request  with  existing  plans  to  see  if  what  is 
requested  is  really  required.  (3)  Is  request  mission 
essential . 

18  (1)  Follow  the  P.M.'s  Design  and  Construction  Manual. 

(2)  Professional  experience.  (3)  Individual  talent. 

19  (1)  Cost  of  request.  (2)  Is  request  within  scope.  (3) 
Economic  analysis.  (4)  In  borderline  cases,  consider 
how  important  is  it  to  meet  project  and  customer  goals 
while  at  the  same  time  meeting  Air  Force  execution 
goals. 

20  (1)  Personal  experience.  (2)  Knowledge  of  user  and 
user's  mission,  (3)  Design  status.  (4)  Historical 
guidance  on  change  requests,  say  from  Air  Staff.  (5) 
Cost. 

21  (1)  How  strong  is  justification.  (2)  Is  request 
mission  essential.  (3)  What  is  MAJCOM's  opinion 
towards  request.  (4)  Cost  impact.  (5)  Time  impact. 

(6)  Functionality  impact. 

22  (1)  How  bad  is  the  request  needed.  (2)  Cost  of 
request.  (3)  Sensibility.  (4)  Constructability. 

23  (1)  What  is  best  for  overall  Air  Force.  (2)  What  is 
best  for  the  BCE.  (3)  What  is  best  for  the  user.  (4) 
Cost  of  request.  (5)  How  will  request  impact  schedule. 
(6)  Evaluate  the  request  in  terms  of  wants  versus  the 
construction  status. 

24  (1)  Funds  availability.  (2)  In  construction,  will 
contractor  have  to  rework  work  already  completed.  (3) 
Is  request  mission  essential.  (4)  Is  it  legal  to 
incorporate  request  (e.g.  in  terms  of  project  scope, 
etc)  . 

25  (1)  Impact  on  schedule.  (2)  Cost  of  request.  (3) 
Project  critical  need  date.  (4)  Air  Force  goals.  (5) 
How  much  does  request  support  mission.  (6)  How  much 
does  change  improve  morale.  (7)  Community  appearance. 
(8)  Smart  idea  at  the  wrong  time.  (9)  Are  other 
options  available  for  request.  (10)  Availability  of 
funds.  (11)  What  is  magnitude  of  change.  (12)  When 
will  funds  expire. 

26  (1)  Is  there  another  way  to  satisfy  the  requirement. 

(2)  Is  request  from  right  level  of  authority,  e.g.  base 
user  submitting  request  without  coordination  or  support 
of  MAJCOM  user.  (3)  Cost-benefit  ratio. 
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27  (1)  Will  request  functionally  improve  facility.  (2) 

Can  request  be  implemented  in  a  timely  manner  without 
delaying  project.  (3)  What  is  project  critical  need 
date.  (4)  Can  request  be  incorporated  in  an 
administrative  manner,  rather  than  a  change  in 
construction. 

h.  How  are  these  factors  organized  (in  terms  of  a 
checklist,  flowchart,  etc)? 

1  No  formal  organization. 

2  No  formal  organization. 

3  - 

4  No  organization,  intuitive  process. 

5  Project  books  have  checklists  to  follow. 

6  Personal  intuitive  process. 

7  No  formal  guidance. 

8  Personal  intuitive  process. 

9  Situation  dictates. 

10  No  formal  organization. 

11  No  formal  organization. 

12  No  formal  organization. 

13  No  organization. 

14  No  organization. 

15  In  a  operating  instruction. 

16  Intuition.  Changes  not  recognized  as  normal  business. 

17  Own  personal  organization. 

18  No  formal  organization. 

19  No  checklist. 

20  No  formal  guidance. 

21  No  checklist  or  flowchart  used. 

22  No  formal  organization, 

23  No  formal  organization. 

24  Organization  in  Project  Managers  Guidebook. 

25  No  formal  organization. 

26  No  formal  organization. 

27  No  flow  charts  used. 

i.  Have  your  factors  from  above  been  officially 
approved,  in  other  words  signed  in  a  letter  or  included  as 
part  of  a  management  plan,  etc? 

(1)  If  yes,  go  to  question  3 j . 

(2)  If  no,  go  to  question  31. 

1  N 

2  N 

3  - 

4  N 

5  Y 

6  N 

7  N 

8  N 
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9  N 


10 

N 

11 

N, 

except 

construction  aspect  -  Y 

12 

N 

13 

Y 

14 

Y 

15 

N 

16 

Y 

17 

N 

18 

N 

19 

N, 

except 

for  mission 

beddown  projects. 

20 

N, 

except 

for  certain 

projects. 

21 

N 

22 

N 

23 

N 

24 

N, 

except 

for  certain 

projects. 

25 

N 

26 

N, 

except 

for  certain 

projects . 

27 

N 

1 

j  • 

Who  approved  your 

factors? 

2 

3 

— 

- 

4  Factors  are  based  on  the  philosophy  that  you  can 
control  only  two  of  the  following  three:  cost,  quality, 
or  schedule. 

5  Air  Force 

6  - 

7  - 

8  - 

9  - 

10  - 

11  - 

12  - 

13  Engineering  and  Services. 

14  Facility  change  board. 

15  - 

16  P.M.  or  supervisors. 

17  - 

18  - 

19  - 

20  - 

21  - 

22  - 

23  - 

24  - 

25  - 

26  - 

27  - 
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k.  Prior  to  the  approval,  who  did  you  discuss  or 
coordinate  your  factors  with? 

1  - 

2  - 

3  - 

4  - 

5  - 

6  - 

7  - 

8  - 

9  P.M.  discussed  criteria  with  user,  BCE,  A/E,  agent, 
resident  engineer,  SP,  comm,  or  applicable  organizations 
before  predesign  meeting. 

10  - 

11  - 

12  - 

13  The  boss. 

14  The  users. 

15  - 

16  - 

17  - 

18  - 

19  - 

20  - 

21  - 

22  - 

23  - 

24  - 

25  Factors  are  from  organizational  philosophy,  and 
unwritten. 

26  - 

27  - 


1.  Are  there  any  factors  you  do  not  use,  but  think 
should  be  used  to  evaluate  these  requests  for  changes  in 
design  criteria  or  contract  modifications? 

(1)  If  yes,  go  to  question  3m. 

(2)  If  no,  go  to  question  4. 

1  Y 

2  N 

3  N 

4  N 

5  N 

6  N 

7  Y 

8  Y 

9  N 

10  N 

11  N 

12  N 
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13  N 

14  N 

15  N 

16  N 

17  Y 

18  N 

19  N 

20  N 

21  N 

22  N 

23  N 

24  Y 

25  N 

26  N 

27  Y 

m.  What  are  these  factors,  and  why  are  these  factors 
not  being  used  to  evaluate  these  requests? 

1  Exclude  politics  (hard  to  do) . 

2  - 

3  - 

4  - 

5  - 

6  - 

7  Guidance  from  89-1.  P.M.  can  not  defend  position  by 
following  regulation  because  user  does  not  want  to  hear 
C.  E.  say  "we  can  not  do  it  because  the  reg  says  so." 

8  Consider  changing  the  1391  to  increase  project  scope 
(hard  to  do,  since  Congressionally  approved) . 

9  - 

10  - 

11  - 

12  - 

13  - 

14  - 

15  - 

16  - 

17  MAJCOM  should  verify  if  request  is  mission  essential. 

18  - 

19  - 

20  Technical  and  industry  manuals  that  deals  with  aspects 
of  request.  Commanders  may  not  be  aware  of  details. 

21  - 

22  - 

23  - 

24  Timing  when  requests  are  identified.  Need  to  sort  out 
personal  preferences  versus  essential  requests. 

25  - 

26  - 

27  Personal  preferences  should  be  eliminated. 
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4.  The  following  questions  relate  the  user  change  request 
to  the  project  status.  Consider  the  following  two  items: 
(1)  the  factors  you  use  to  evaluate  users,  or  other 
organizations,  requesting  changes  in  design  criteria  or 
contract  modifications;  and  (2)  the  current  completion 
status  of  the  project... 

a.  Do  your  factors  to  evaluate  these  requests  differ 
when  the  project  is  in  design,  at  contracting,  or  under 
construction? 

(1)  If  yes,  go  to  question  4b. 

(2)  If  no,  go  to  question  5. 


1 

2 

3 

4 

5 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 
27 


Y 

Y 
N 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 
N 
N 
N 

Y 

Y 

Y 

Y 
N 

Y 

Y 

Y 

Y 

Y 

Y 

Y 

Y 


b.  What  are  these  differences  and  how  do  they  vary 
between  the  design,  contracting,  and  construction  phases? 

1  Less  expensive  to  incorporate  change  in  design,  unless 
change  delays  execution  (e.g.  bid  opening) . 

2  More  likely  to  approve  changes  (thus  less  scrutinized) 
in  design  versus  in  contracting  or  under  construction. 
While  at  contracting,  consider  time  of  fiscal  year, 
balance  that  out  with  user  need  of  project. 

3  - 
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4  In  design  or  contracting,  look  at  need  date  then  decide 
how  close  to  look  at  change  reguest.  In  construction, 
tends  to  be  more  lenient,  but  also  considers  if  work 
can  be  done  by  a  follow-on  contract. 

5  Design,  compare  change  to  scope  and  costs.  In 
contracting  and  construction,  compare  change  to  project 
scope. 

6  Factors  are  same,  weights  change.  In  construction, 
look  at  cost  of  modification  and  when  can  it  be 
incorporated  into  project  (maybe  wait  until  end  of 
project) .  In  contracting,  changes  are  closely 
scrutinized  because  of  strong  desire  to  award  project. 

7  More  strict  as  proceeding  from  design  through 
construction. 

8  Less  expensive  to  make  changes  in  design,  rather  than 
construction. 

9  Situation  dictates.  Less  expensive  to  stop  a 
construction  contractor  rather  than  an  A/E.  In  design 
and  contracting,  consider  how  flexible  the  milestones 
are.  In  construction,  consider  the  cost  of  the  change 
versus  money  available. 

10  Changes  during  design  and  contracting  cost  less  than 
changes  in  construction. 

11  In  design,  P.M.  just  manages  a  schedule.  In 
construction,  P.M.  must  manage  a  contract. 

12  - 

13  - 

14  - 

15  In  design,  more  liberal  with  changes,  but  concerned 
about  costs,  also  trys  to  eliminate  ridiculous  changes. 
In  construction,  changes  are  more  stringently  looked 
at. 

16  In  design,  look  at  criteria,  scope,  and  cost.  In 
contracting,  look  at  criteria,  and  if  change  will 
provide  a  complete  and  usable  facility.  In 
construction,  look  at  scope  and  cost  growth. 

17  In  construction,  need  to  ask  user  if  willing  to  slip 
beneficial  occupancy  date.  In  contracting,  P.M.  is 
willing  to  incorporate  if  there  is  enough  time  to  amend 
the  bid  package  without  slipping  the  bid  opening  date. 

18  Should  be  no  user  requests  after  35  percent  design. 

Try  to  talk  user  out  of  request.  If  needed,  design  are 
better  than  construction  changes  because  changing  a 
design  involves  only  changing  paper. 

19  - 

20  In  design  there  is  more  flexibility  to  accommodate 
change  requests.  At  contracting,  do  not  want  to  impact 
the  bid  opening  date. 

21  More  lenient  to  incorporate  request  in  early  stages  of 
design. 

22  Increasing  hesentency  to  incorporate  change  when 
project  is  design  versus  contracting  versus 
construction. 
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23  In  construction,  less  likely  to  implement  change. 

Also,  in  construction  consider  the  relations  between 
the  Air  Force  and  the  contractor. 

24  In  design,  it  is  easier  to  incorporate  a  change  versus 
if  the  project  is  in  contracting  or  construction. 

25  Timing  of  the  request  impacts  costs.  The  earlier  the 
change  is  identified,  the  less  it  will  cost  to 
incorporate  the  request. 

26  In  design,  the  goal  is  to  meet  the  schedule.  In 
construction,  the  goal  is  to  meet  the  costs  (so 
different  approaches  are  sought  to  incorporate  the 
request,  rather  than  using  construction) . 

27  To  incorporate  a  change  costs  more  in  construction, 
rather  than  design.  So  the  request  is  looked  at  more 
closely  in  construction  rather  than  design. 

5.  The  following  questions  concern  the  ranking  of  each 
specific  evaluation  factor  you  provided  above.  Consider 
categorizing  your  evaluation  factors... 

a.  How  important  is  it  to  know  the  answer  to  each  of 
your  specific  factors  when  evaluating  a  user  change 
request.  Select  from  one  of  the  categories  below. 

(1)  It  is  important  for  me  to  know  the  answer  for 
that  particular  factor. 

(2)  It  is  moderately  important  for  me  to  know  the 
answer  for  that  particular  factor. 

(3)  It  is  not-to- important  for  me  to  know  the 
answer  for  that  particular  factor. 


1 

(1)  , 

(2)  , 

(3)  , 

(4)  , 

(5)  , 

(6) 

-  1. 

2 

T 

(1)  , 

(2)  , 

(3) 

-  1. 

(4) 

-  2. 

(5) 

-  1. 

■J 

4 

(1)  ■ 

-  1. 

(2) 

-  2. 

(3) 

-  1. 

(4)  , 

(5) 

-  2.  (6) 

(7)  , 

(8) 

-  2. 

5 

(1)  ■ 

-  2. 

(2) 

-  1. 

(3) 

-  2. 

6 

(1), 

(2)  , 

(3) 

-  1. 

(4) 

-  2. 

(5) 

-  1. 

(6)  -  2. 

7 

(1)  , 

(2)  , 

(3) 

-  1. 

8 

(1)  , 

(2) 

-  1. 

(3) 

-  2. 

(4) 

-  1. 

9 

(1)  , 

(2)  , 

(3)  , 

(4)  , 

(5)  , 

(6)  , 

(7)  , 

(8)  , 

(9)  -  1. 

10 

(1)  , 

(2)  , 

(3) 

-  1. 

11 

(1)  , 

(2)  , 

(3)  , 

(4)  , 

(5) 

-  1. 

12 

(1)  , 

(2)  , 

(3) 

-  1. 

13 

(1)  , 

(2)  , 

(3)  , 

(4) 

-  1. 

14 

(1)  , 

(2)  , 

(3) 

-  1. 

15 

— 

16 

(1)  , 

(2) 

-  1. 

17 

(1)  , 

(2)  , 

(3) 

-  1. 

18 

(1)  , 

(2)  , 

(3) 

-  1. 

19 

(1)  , 

(2) 

-  1. 

(3) 

-  2. 

(4) 

-  1. 

20 

(1)  , 

(2), 

(3) 

-  1. 

(4)  , 

(5) 

-  2. 

21 

(1), 

(2) 

-  2. 

(3)  , 

(4) 

-  1. 

(5)  , 

(6) 

-  2. 
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22 

(1)  , 

(2) 

-  1. 

(3) 

-  2. 

(4) 

-  1. 

23 

(1)  , 

(2) 

-  2. 

(3)  , 

^  (4), 

(5)  , 

(6) 

-  1. 

24 

(1), 

(2) 

,  (3), 

(4) 

-  1. 

25 

(1)  , 

(2) 

,  (3)  - 

1. 

(4) 

-  3. 

(5) 

-  1.  (6)  -  2. 

(7)  - 

1. 

(8)  - 

2. 

(9)  , 

(10) 

-  1. 

(11) ,  (12)  -  varies 

based 

on 

status 

• 

26 

(1), 

(2) 

-  1. 

(3) 

-  3. 

27 

(1)  - 

1. 

(2)  - 

2. 

(3)  - 

3. 

(4)  - 

2. 

b.  How  difficult  is  it  to  obtain  an  answer  to  each  of 
your  specific  factors  when  evaluating  a  user  change 
request.  Select  from  one  of  the  categories  below. 

(1)  It  is  easy  to  obtain  an  answer  to  this  factor. 

(2)  It  is  moderately  difficult  to  obtain  an  answer 
to  this  factor. 

(3)  It  is  difficult  to  obtain  an  answer  to  this 
factor. 


1 

(1)/ 

(2) 

,  (3) 

-  1. 

(4)  - 

3. 

(5) 

-  1. 

(6) 

-  3. 

2 

*1 

(1) 

-  1. 

(2)  , 

(3)  , 

(4)  - 

2. 

(5) 

-  1. 

4 

(1) 

-  3. 

(2) 

-  1. 

(3)  , 

(4) 

-  2. 

(5)  , 

(6) 

-  1. 

(7), 

(8) 

-  2. 

5 

(1)  , 

(2) 

,  (3) 

-  1. 

6 

(1) 

-  2. 

(2), 

(3) 

-  1. 

(4), 

(5) 

-  2. 

(6) 

-  1. 

7 

(1), 

(2) 

-  3. 

(3) 

-  1. 

8 

(1)  , 

(2) 

-  2. 

(3) 

-  3. 

(4) 

-  2. 

9 

(1)  , 

(2) 

,  (3)  , 

(4), 

(5), 

(6), 

(7) 

,  (8), 

(9) 

-  1. 

10 

(1) 

-  2. 

(2)  , 

(3) 

-  3. 

11 

(1) 

-  2. 

(2) 

-  3. 

(3)  - 

2. 

(4) 

“  3. 

(5) 

-  2. 

12 

(1)  , 

(2) 

-  1. 

(3) 

-  2. 

13 

(1)  , 

(2) 

,  (3) 

-  2. 

(4)  - 

1. 

14 

(1)  , 

(2) 

,  (3) 

-  1. 

15 

— 

16 

(1)  , 

(2) 

-  2. 

17 

(1) 

-  1. 

(2) 

-  2. 

(3)  - 

1. 

18 

(1)  , 

(2) 

-  1. 

(3) 

-  3. 

19 

(1) 

-  2. 

(2) 

-  1. 

(3)  - 

3  . 

(4) 

-  1. 

20 

(1) 

-  1. 

(2) 

-  2. 

(3)  - 

1. 

(4) 

,  (5) 

-  2. 

21 

(1)  , 

(2) 

-  2. 

(3) 

-  1. 

(4) 

-  2. 

(5)  , 

(6) 

-  3. 

22 

(1) 

-  varies. 

(2) 

-  1. 

(3) 

-  varies. 

(4) 

-  1. 

23 

(1), 

(2) 

-  1. 

(3) 

-  2. 

(4), 

(5) 

-  1. 

(6) 

-  2. 

24 

(1) 

-  1. 

(2) 

-  3. 

(3), 

(4) 

-  1. 

25 

(1) 

-  2. 

(2)  , 

(3)  , 

(4)  - 

1. 

(5) 

,  (6)  , 

(7)  , 

(8) 

(9) 

-  2. 

(10) 

-  1. 

(11) 

-  2 

.  (12)  - 

1. 

26 

(1)  , 

(2) 

,  (3) 

-  1. 

27 

(1)  , 

(2) 

-  2. 

(3) 

-  1. 

(4) 

-  3. 

6.  The  following  questions  are  about  the  approval  process 
of  the  user  requested  change  in  design  criteria  or 
requested  contract  modification.  Consider  the  formal 
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procedures  you  use  to  approve  or  disapprove  the  user 
request  .  .  . 

a.  Does  either  the  user  requested  change  in  design 
criteria  or  construction  modification  require  formal 
approval? 

(1)  If  yes,  go  to  question  6b. 

(2)  If  no,  go  to  question  6e. 

1  N 

2  Y 

3  - 

4  Y 

5  Y  (only  if  violates  AFM  88-15,  ETLs  or  CTLs) 

6  Y 

7  Y 

8  Y 

9  Y 

10  Y 

11  Y  (construction  only) 

12  Y 

13  Y 

14  Y 

15  Y 

16  Y 

17  Y 

18  Depends  on  request  itself,  and  powers  of  persuasion. 

19  Y 

20  Y 

21  N 

22  Case-by-case  basis. 

23  Y 

24  Y 

25  Y 

26  Y 

27  Y 

b.  Describe  the  formal  approval  process,  in  terms  of 
(1)  who  is  involved;  (2)  what  do  they  do;  and  (3)  how  do 
they  do  it. 


1  - 

2  Using  agency  sends  request  to  BCE.  BCE  does  quick  cost 
estimate,  and  initial  screening.  Then  request  sent  to 
MAJCOM,  for  coordination.  Then  decision  made.  If 
approved,  sent  to  Corps.  If  disapproved,  sent  back  to 
base. 

3  - 

4  User,  agent,  AFRCE,  MAJCOM,  SATAF,  BCE,  XB  are 
organizations  involved.  Design  is  less  formal  process, 
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as  compared  to  construction.  Weekly  construction 
management  meetings  held. 

5  Go  to  Air  Staff  asking  for  approvals  or  waivers. 

6  MAJCOM  DE  approval  required  on  changes  that  impact  firm 
dates  (i.e.  provided  to  Corps)  on  major  beddowns. 

7  User  asks  for  change.  Cost  estimate  obtained  from 
Corps.  If  money  available  and  reasonable  request,  then 
change  incorporated.  If  not,  then  change  request 
returned. 

8  From  user  to  base  DEE,  who  submits  to  MAJCOM,  who  sends 
to  Corps.  Informal  cost  estimate  and  impacts  obtained, 
this  information  used  to  make  decision. 

9  From  user,  to  BCE  (who  validated  request) .  Then 
request  sent  to  AFRCE  (on  site  representative) .  If 
less  than  $2 5k,  then  given  to  agent.  If  more  than 
$2 5k,  MAJCOM  approval  required. 

10  Base  handles  all  changes  whose  combined  dollar  value  is 
less  than  the  management  reserve.  Otherwise,  MAJCOM 
approval  required. 

11  Requests  are  discussed  at  construction  board,  who  meets 
on  a  regular  basis. 

12  User  identifies  why  request  is  required.  P.M.  obtains 
cost  estimate.  P.M.  obtains  coordination  of  his  boss. 

13  Determine  cost  of  change  request.  Then  check  if 
request  is  nice-to-have  versus  required.  If  required, 
then  pass  request  on  to  engineers. 

14  Decisions  made  at  FAB  board.  Board  consists  of  user, 
design  and  construction  agents,  and  applicable 
organizations. 

15  AFRCE  resident  engineer  responsible  for  approval/ 
disapproval  of  requests  up  to  $50k.  Main  office  AFRCE 
approval  required  for  changes  greater  than  $50k. 

16  Facilities  change  board  (consisting  of  user,  AFRCE,  and 
other  agencies  involved)  reviews  change  request  against 
project  book  criteria. 

17  Request  goes  from  base  to  MAJCOM  to  AFRCE.  MAJCOM 
approves.  AFRCE  implements,  and  determines  if  the 
request  is  in  the  best  interest  of  the  project. 

18  Decisions  made  at  the  design  conference. 

19  Request  goes  from  base  to  MAJCOM  (determines  validity 
of  change)  to  AFRCE. 

20  Request  goes  from  MAJCOM  to  AFRCE  to  design  or 
construction  agent. 

21  User  submits  change  to  BCE  and  command  users. 

22  P.M.  works  with  MAJCOM  to  incorporate  request. 

23  P.M.  works  with  point  of  contact  on  base.  To  save 
time,  P.M.  will  implement  request. 

24  Request  goes  from  user  to  BCE  to  MAJCOM  to  AFRCE  to 
design  or  construction  agent. 

25  Design  is  informal  process,  as  requests  are  brought  up 
and  evaluated  at  design  conferences.  More  formal 
process  in  construction,  as  request  is  sent  from  MAJCOM 
to  AFRCE  to  design  or  construction  agent. 
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26  In  design,  request  goes  from  user  to  MAJCOM  to  AFRCE  to 
Corps.  In  construction,  when  P.M.  receives  a  request 
he  will  implement  it  (as  long  as  management  reserve 
exists) . 

27  Request  goes  from  user  to  MAJCOM  to  AFRCE  to  Corps, 

c.  Is  there  a  written  document  that  establishes  that 
formal  approval  process? 

(1)  If  yes,  go  to  question  6d. 

(2)  If  no,  go  to  question  6e. 

1  - 

2  Y 

3  - 

4  Y 

5  N 

6  N 

7  N 

8  Y 

9  Y 

10  Y 

11  N  -  design.  Y  -  construction. 

12  N 

13  Y 

14  Y 

15  Y 

16  Y 

17  Y 

18  Y 

19  Y 

20  i 

21  - 

22  Y 

23  N 

24  Y 

25  Y 

26  Y 

27  Y 

d.  Describe  this  document (s)  and  when  was  it 
published,  in  relation  to  the  project? 

1  - 

2  Management  plans.  MAJCOM  delegation  of  some  changes  to 
base  letter. 

3  - 

4  B-1,  B-2  Management  Plans.  Published  after  design  and 
before  construction. 

5  - 

6  - 

7  - 

8  Larger  projects  have  formal  management  plans. 
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9  B-1  Management  Plan. 

10  Can  not  recall  document. 

11  Management  plan. 

12  - 

13  Management  plan. 

14  Management  plan. 

15  Operating  Instructions. 

16  Facility  Acquisition  Strategy  Plan.  Normally  published 
prior  to  design. 

17  89-1.  Mission  beddown  had  a  specific  management  plan. 

18  Project  Managers'  Handbook. 

19  89-1. 

20  89-1  and  Project  Managers'  Handbook. 

21  - 

22  89-1. 

23  - 

24  89-1. 

25  89-1. 

26  Project  Manager's  Handbook. 

27  89-1. 

e.  Do  the  approval  policies  on  user  requests  vary  for 
different  projects? 

(1)  If  yes,  go  to  question  6f. 

(2)  If  no,  go  to  question  7. 

1  N 

2  Y 

3  - 

4  N 

5  N 

6  y 

7  Y 

8  Y 

9  Y 

10  N 

11  N 

12  Y 

13  N 

14  N 

15  N 

16  N 

17  Y 

18  N 

19  Y 

20  N 

21  Y 

22  Y 

23  Y 

24  N 

25  N 
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26  Y 

27  Y 

f.  Describe  the  difference  in  the  approval  policies. 

2  If  cost  of  change  is  below  a  certain  limit,  can  be 
delegated  to  base. 

3  - 

4  - 

5  - 

6  Depends  on  project  type  and  its  visibility. 

7  Nothing  is  standard.  Unless  change  impacts  scope  or 
cost  to  the  point  where  Air  Staff  approval  is  required. 

8  If  cost  of  change  is  below  a  certain  limit,  can  be 
delegated  to  base. 

9  Varies  based  on  BOS  or  beddown  project. 

10  - 

11  - 

12  Varies  based  on  project. 

13  - 

14  - 

15  - 

16  - 

17  Medical  projects  have  their  additional  organizations 
that  must  coordinate  on  request. 

18  - 

19  Varies  only  when  management  plan  exists. 

20  - 

21  Larger  projects  have  a  more  formal  approval  process. 

22  Interpretation  of  the  regulations  and  policies  are 
different  for  each  command  and  user. 

23  Varies  by  command. 

24  - 

25  - 

26  Depends  on  who  is  driving  the  request. 

27  Medical  projects  and  requests  over  $100k  require 
additional  organizations  to  coordinate  on  the  request. 

7.  The  following  questions  concern  the  coordination  of  a 
requested  change  in  design  criteria  or  contract 
modification.  Consider  the  organizations  that  coordinate 
on  the  request  .  .  . 

a.  Is  the  user  requested  change  in  design  criteria  or 
requested  contract  modification  coordinated  with  third 
organizations  (other  than  the  one  submitting  the  change 
request) ? 

(1)  If  yes,  go  to  question  7b. 

(2)  If  no,  go  to  question  7e. 
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1  Y 

2  Y 

3  - 

4  Y 

5  Y 

6  Y 

7  Y 

8  Y 

9  Y 

10  Y 

11  Y 

12  Y 

13  Y 

14  Y 

15  Y 

16  Y 

17  Y 

18  Y,  normally  coordination  accomplished  before  P.M. 
receives  request. 

19  Y 

20  Y 

21  Y 

22  Y,  in  some  instances. 

23  Y,  in  some  instances. 

24  Y 

25  Y 

26  Y 

27  Y 

b.  For  each  request,  is  coordination  obtained  from  all 
agencies  involved  with  the  project? 

(1)  If  no,  go  to  question  7c. 

(2)  If  yes,  go  to  question  7d. 

1  N 

2  Y 

3  - 

4  Y 

5  Y 

6  Y 

7  Y 

8  N 

9  Y  (applicable  agencies) 

10  Y 

11  Y 

12  N 

13  Y 

14  Y 

15  Y 

16  Y 

17  Y 
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Y  (coordinated  with  agencies  that  have  a  need-to-know. 
Other  agencies  receive  info  copies) . 

20  N 

21  Y  (all  agencies  at  least  notified) . 

22  Y 

23  N 

24  N 

25  Y  (qualified  by  type  of  change) . 

26  N  (depends  on  agencies  affected) . 

27  Y 

c.  What  agencies  are  typically  coordinated  with? 

1  Always  coordinate  with  design  and  construction  agent. 
Other  agencies  are  based  on  P.M.'s  determination  of  a 
need  to  know. 

2  Varies  based  on  type  of  project.  Other  agencies  are 
based  on  P.M.'s  determination  of  a  need  to  know. 

3  - 

4  - 

5  - 

6  - 

7  SP,  communications. 

8  Communications,  SP,  user,  DEM,  DEV. 

9  SP,  communications,  BCE  (DEM,  DEE),  user,  user's  boss, 
building  occupant  counterpart,  applicable  organization 
in  MAJCOM  and  other  MAJCOMs. 

10  - 

11  - 

12  BCE  organization. 

13  MAJCOMs,  SPOs,  user.  Corps. 

14  - 

15  All  agencies  are  invited  to  comment.  If  P.M.  does  not 
hear  from  agency,  then  assume  agency  concurs. 

16  - 

17  - 

18  - 

19  - 

20  Any  applicable  organization. 

21  Host  and  user  command. 

22  - 

23  Agencies  that  have  a  need-to-know. 

24  Communications. 

25  Fire  department,  safety,  multiple  users. 

26  Agencies  that  have  a  need-to-know. 

27  - 

d.  How  do  you  obtain  this  coordination? 

1  By  phone.  Sensitive  issues,  send  letter  out  to 
applicable  agencies. 

2  Write  up  response,  then  obtain  coordination  from 
various  agencies. 
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3  - 

4  At  weekly  meetings  (talk  about  request,  if  more  info  is 
needed  then  XB  drives  requests) . 

5  Phone  (to  tell  organization  of  a  change) ,  then  follow 
up  with  a  letter. 

6  Through  group  meetings.  Phone  coordination. 

7  Use  buc  slip  for  DE  offices.  Formal  coordination  from 
offices  outside  DE. 

8  Formal  letter  to  MAJCOM  counterpart. 

9  Varies  -  verbally  to  writing. 

10  Phone  calls  and  memos. 

11  Design  -  formal  review  conference.  Construction  - 
working  groups. 

12  BCE  assists  with  coordination. 

13  By  letter.  If  urgent,  then  verbally. 

14  All  organizations  sign  off  on  the  form  containing  the 
facility  engineering  change  proposal. 

15  Use  the  "AFRCE  form." 

16  At  the  facilities  engineering  change  board. 

17  MAJCOM  does  coordination. 

18  - 

19  Phone  calls. 

20  Phone  calls. 

21  Use  phone  calls  and  memos  to  notify  agencies.  In 
writing  obtain  coordination  from  agencies. 

22  In  writing. 

23  Phone  calls.  Follow  up  with  a  message  or  letter. 

24  In  writing. 

25  Phone  calls. 

26  Letters  and/or  messages. 

27  Phone  calls. 

e.  Have  you  been  in  situations  were  that  original 
request  had  to  be  revised? 

(1)  If  yes,  go  to  question  7f.  ^ 

(2)  If  no,  go  to  paragraph  8. 

1  Y 

2  Y 

3  - 

4  Y 

5  Y 

6  Y 

7  Y 

8  Y 

9  Y 

10  Y 

11  Y 

12  Y 

13  Y 

14  Y 

15  Y 

16  Y 


123 


17  Y 

18  N 

19  Y 

20  Y 

21  Y 

22  Y 

23  Y 

24  Y 

25  Y 

26  Y 

27  Y 

f.  What  circumstances  caused  this  revision? 

1  Funds  availability. 

2  Poor  planning  (someone  did  not  think  the  process 
through) . 

3  - 

4  New  or  bad  information.  Constructability  problems. 
Change  request  was  out  of  scope.  Great  idea  at  wrong 
time. 

5  Change  request  was  out  of  scope.  Engineers 
misunderstood  request. 

6  Change  in  equipment.  Change  in  chain-of -command. 

Change  in  mission. 

7  Change  in  personnel.  Personnel  changing  their  minds. 
Change  in  mission. 

8  New  info  brought  out  during  coordination. 

9  Late  breaking  criteria. 

10  Cost  of  request,  compromise  reached  during  technical 
evaluation. 

11  Design  accomplished  at  same  time  as  R  and  D  work. 

12  Change  involved  historical  facilities. 

13  Not  enough  money  for  change.  No  urgent  need  to  do 
change. 

14  Inadequate  data. 

15  Lack  of  knowledge  of  person  submitting  change. 

16  Maturity  of  construction  criteria. 

17  BCE  or  MAJCOM  or  AFRCE  may  not  concur  with  request. 

BCE  identifies  technical  reason. 

18  - 

19  Further  studying  of  request  reveals  that  change  is  not 
needed . 

20  MAJCOM  desires. 

21  Many  reasons.  Changed  site  conditions.  Cost.  Legal 
aspect  of  request.  Time  impact.  Other  persons  stating 
impacts  of  change  on  their  agency. 

22  BCE  maintainability.  Availability  of  spare  parts. 
Accessibility. 

23  Equipment  arrival  dates. 

24  Users  were  not  able  to  visualize  the  blueprints. 
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25  Incomplete  coordination.  In  addition,  agencies  did  not 
completely  understand  change  or  have  all  the 
information  about  the  change. 

26  Cost  of  request. 

27  Real  requirement  brought  out  in  coordination  process 
(e.g.  requirement  was  for  security  storage  not  security 
vault) . 

g.  How  long  after  the  request  was  submitted  did  this 
revision  occur? 

1  Hours . 

2  Days. 

3  - 

4  Months . 

5  Two  to  three  weeks. . 

6  Varies  from  a  week  until  after  facility  was  complete. 

7  Week  to  two  months. 

8  Two  weeks 

9  Situational. 

10  Few  weeks. 

11  Months. 

12  Three  weeks. 

13  A  week. 

14  Two  to  three  weeks  for  design  changes.  Four  to  six 
weeks  for  construction  changes. 

15  A  week. 

16  Immediately  to  three  months. 

17  Six  weeks. 

18  - 

19  Varies  from  weeks  to  months. 

20  A  week. 

21  A  week. 

22  Varies,  one  day  was  best  time. 

23  Four  to  five  months. 

24  Could  not  recall. 

25  Hours  to  three  months. 

26  Varies  two  to  five  months. 

27  Six  months. 


8.  THE  END  OF  INTERVIEW!!! 
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Appendix  C:  Distribution  of  Evaluation  Factors 
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Table  C.l  (Continued) 
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Appendix  D:  Reasons  to  Change  the  Request 


Table  D.l 

Frequency  Count  of  the  Various  Circumstances  that  Caused 
a  Revision  to  the  Original  Requested  Change 


Response 

Count 

Percent 

Funds  availability 

5 

20 

Poor  planning 

New  information  no  one  could  have 

1 

4 

control  over 

2 

8 

Bad  information 

3 

12 

Const ructab i 1 ity 

1 

4 

Out  of  scope  idea 

3 

12 

Great  idea  at  wrong  time 

1 

4 

Engineering  misunderstood  request 

2 

8 

Equipment  change 

2 

8 

Personnel  change 

2 

8 

Mission  change 

2 

8 

Personnel  changing  their  minds 

New  information  brought  out  during 

2 

8 

coordination 

Design  accomplished  at  same  time  as 

2 

8 

RD  work 

2 

8 

Historical  facilities  involved 

1 

4 

Request  was  not  so  urgent 

Office  not  concurring  for  technical 

2 

8 

reasons 

1 

4 

Time  impact  of  request 

1 

4 

Changed  site  conditions 

1 

4 

Maintainability 

1 

4 

Spare  parts 

1 

4 

Users  could  not  visualize  blueprints 

1 

4 

Incomplete  coordination 

Real  requirement  brought  in 

1 

4 

coordination  process 

1 

4 
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Table  E.l 


Frequency  Count  of  the  Various  Circumstances  that  Caused 
Revisions  to  the  Original  Requested  Change 


Response  Count  Percent 


Less  expensive  to  incorporate  change  in 
design,  rather  than  in  contracting  and 
construction.  Look  more  closely  at 
changes  in  contracting  or  construction. 

More  flexible  to  accommodate  request 

in  design.  16  64 

At  contracting,  look  at  time  in  fiscal  year, 
balance  with  Air  Force  milestones  and  user 
need  of  project.  5  20 

In  construction,  consider  if  work  can  be 

done  by  follow-on  contract.  1  4 

More  lenient  with  requests  in  construction.  1  4 

In  design,  compare  change  to  scope  and 
costs.  In  contracting  or  construction, 

compare  to  project  scope.  1  4 

Factors  are  same,  weights  change.  1  4 

In  construction,  more  likely  to  make  change 
at  end  of  project  and  if  management 

reserve  is  available.  2  8 

In  design  and  contracting,  P.M.  considers 
milestone  impacts.  In  construction,  P.M. 
considers  money  impacts.  3  12 

In  construction,  is  user  willing  to  slip 

beneficial  occupancy  date.  1  4 


In  design,  look  at  criteria,  scope,  and 
cost.  In  contracting,  look  at  criteria, 
and  if  change  will  provide  a  complete 
and  usable  facility.  In  construction, 

look  at  scope  and  cost  growth.  1  4 

Should  be  no  requests  after  35  percent 

design.  Talk  users  out  of  it.  1  4 

In  construction,  consider  the  relations 

between  the  contractor  and  Air  Force.  1  4 


129 


Appendix  F:  Various  Types  of  Approval  Processes 


Table  F.l 

Frequency  Count  of  Various  Types  of  Approval 
Processes  on  Requested  User  Changes 


Response 

Count 

Percent 

Using  agency  requests  the  base  for  change. 
Coordination  is  accomplished  at  base 
level.  Request  sent  to  MAJCOM. 
Coordination  is  accomplished  at  MAJCOM. 
Request  sent  to  AFCRE.  Coordination  is 
accomplished  with  AFCRE. 

13 

54.2 

Using  agency  requests  the  base  (either 

AFCRE  representative  or  base  Civil 
Engineering)  for  change.  If  change 
costs  below  a  certain  limit,  base  can 
approve  change. 

3 

12.3 

Meetings  held  at  regular  intervals,  all 
players  in  the  construction  process 
(from  Civil  Engineering  to  user)  attend 
meeting  and  changes  are  discussed  and 
finalized  at  the  meeting. 

4 

16.6 

Only  go  to  Air  Staff  to  ask  for  approvals 
or  waivers. 

1 

4.2 

Base  can  handle  all  changes  whose 
cumulative  dollar  value  is  below  a 
certain  management  reserve. 

1 

4.2 

Requests  brought  up  at  design  reviews  and 
decisions  made  at  the  review. 

2 

8.3 

Project  manager  works  with  user  to 
incorporate  as  many  of  reasonable 
requests  as  possible. 

2 

8.3 
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Appendix  G:  Grouping  of  Factors 
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Subtotal  =  32  78  AVG 


Table  G.l  (Continued) 


Appendix  H:  Statistix  Simple  Correlation  Computer  Runs 


SIMPLE  CORRELATIONS 


COUNT 

IMPORT 

DIFF 


COUNT 

1.0000 

0.9889 

-0.0203 


IMPORT 

1.0000 

-0.0130 


CASES  INCLUDED  48 


MISSING 


DIFF 


1.0000 

CASES  0 
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Appendix  I :  An  Understanding  of  Important  Issues  on 
Evaluation  of  User  Requested  Changes 


1.  So  you  thought  your  project  would  present  no  problems 
to  award  in  the  current  fiscal  year,  or  within  the 
authorized  budget  limit.  Remember  that  Civil  Engineering 
is  a  service  organization  and  also  is  in  a  change  oriented 
business,  so  put  two  and  two  together. 

2 .  What  do  you  do  when  the  customer  reguests  a  change  to 
the  design  and/or  construction?  You  can  first  try  looking 
at  AFR  89-1,  Design  and  Construction  Management,  but  most 
of  your  colleagues  will  evaluate  the  requested  change  based 
on  their  past  experience.  If  you  feel  like  you  do  not  have 
a  great  deal  of  past  experience,  then  consider  reading  this 
to  acquire  the  experience  of  one  AFIT  research  effort. 
Important  note:  This  document  is  not  intended  to  supercede 
any  regulation  or  management  plan. 

3.  The  project  manager  should  understand  three  major 

aspects  in  evaluating  user  change  requests.  They  are  the 
following:  (1)  the  early  indicators  of  future  requests, 

(2)  the  administrative  process,  and  (3)  the  evaluation 
factors.  Each  of  these  aspects  is  explained  below. 

4.  Three  classes  of  circumstances  dictate  if  the  users  are 
likely  to  request  changes  in  the  project  later  phases. 

These  circumstances  are  the  following:  (1)  working  with 
information  that  no  one  has  control  over,  (2) 
misunderstandings,  and  (3)  poor  staff  work. 

a.  Table  I.l  shows  specific  circumstances  for  each 
category.  If  misunderstandings  or  poor  staff  work  exists 
in  the  predesign  or  conceptual  design  process,  then  the 
project  may  expect  more  than  a  "fair  share"  of  user 
requests.  A  fair  share  of  requests  are  the  result  of 
information  that  no  one  has  control  over  (e.g.,  mission 
change) . 

b.  It  is  important  for  the  project  manager  to 
recognize  any  or  all  of  the  above  circumstances  during  the 
predesign  phases. 

5.  An  effective  project  manager  does  not  become  just 
reactionary  to  the  user  change  request  process.  Project 
managers  need  to  plan  their  actions  upon  receiving  a  change 
request. 


a.  The  first  item  to  consider  is  just  what  type  of 
project  are  you  managing.  Obviously  it  is  not  an  easy  one; 
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otherwise,  you  would  not  be  involved!  But  some  projects 
are  more  difficult  to  execute  than  others. 

b.  The  next  item  to  consider  is  "do  you  have  a  formal 
management  plan  that  addresses  how  to  process  the  requests, 
and  are  all  players  involved  with  the  construction  aware  of 
that  plan. " 

(1)  Do  all  the  users  and  players  understand  you 
will  use  an  orderly  process  to  evaluate  the  changes?  Do 
they  also  understand  that  process? 

(2)  Before  starting  design,  do  you  have  a  list  of 
all  organizations  involved  (not  just  the  user  ol  the 
organizations  that  the  construction  area  impacts)  and  their 
designated  points  of  contact? 

c.  Does  the  management  plan  address  coordination  of 
the  requested  changes?  Most  project  managers  work  in  an 
environment  where  the  requested  change  requires  formal 
approval  (someone  or  organization  other  than  the  project 
manager) . 

(1)  Do  you  have  regularly  scheduled  meetings 
where  one  agenda  item  is  to  discuss  requested  changes  or 
possible  future  requested  changes? 

(2)  At  these  meetings,  you  should  let  only  one 
person  provide  that  organization's  comments  on  a  requested 
change, 

(3)  Obtain  everything  in  writing.  If  time 
requires  acting  expeditiously,  then  follow  up  with  written 
correspondence . 

d.  A  typical  management  plans  does  not  include 
specific  details  such  as  the  factors  listed  in  Table  1.2. 
These  factors  represent  the  creativity  of  others,  besides 
regulations  and  management  plans,  to  solve  implementation 
problems.  Also,  most  project  managers  feel  their  factors 
have  not  been  officially  approved. 

6.  Ask  an  old  pro  on  evaluating  requested  changes,  and 
he'll  probably  say  "the  situation  dictates."  He  probably 
does  not  realize  that  there  are  three  main  classifications 
that  explain  why  people  act  as  they  do  in  evaluating  user 
requested  changes. 

a.  The  first  is  predispositions  of  the  individual. 
Predispositions  are  the  project  managers'  motives  prior  to 
the  action.  These  motives  could  be  gained  from  common 
sense,  professional  experience,  or  other  sources. 

b.  The  second  is  influences  on  the  individual.  An 
example  is  a  third  organization  who  also  must  coordinate  on 
the  request,  thus  becoming  an  "influence"  on  the  individual 
evaluating  the  change, 

c.  The  third  is  attributes  of  the  request.  These 
include  cost,  schedule  impact,  etc. 

7.  Table  1.2  contains  a  listing  of  the  factors,  obtained 
from  experts,  to  evaluate  requested  changes.  You  may  not 
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need  to  address  all  these  factors  on  individual  changes, 
but  reviewing  the  list  provides  the  experience  of  others. 

a.  The  factors  in  Table  1.2  are  categorized  in  two 

ways. 

(1)  First,  Table  1.2  classifies  the  factors  into 

either  one  of  the  three  classifications  (that  describe  why 
people  act  as  they  do) .  These  classifications  are  the 
following:  (1)  attributes,  (2)  influences,  and  (3) 

predispositions . 

(2)  Second,  the  factors  in  the  "attribute"  and 
"influence"  classifications  are  divided  into  those  that 
deal  with  project  execution  (e.g.  on  time  and  within 
available  resources)  and  facility  quality  (enhancing  user 
productivity) .  A  third  category  is  "others"  (which  does 
not  fit  into  the  "execution"  and  "quality"  categories) . 
Individual  or  agency  opinions  typically  fall  into  this 
third  category. 

b.  Table  1.2  also  includes  the  following  two  scores: 
(1)  a  "Count  and  Importance"  score,  where  a  higher  score 
indicates  more  frequent  use  and  more  importance  associated 
with  that  factor;  and  (2)  "Weighted  Difficulty"  score, 
where  a  score  of  one  means  the  factor  would  be  easy  to 
address  and  a  score  of  three  means  the  factor  would  be 
difficult  to  address. 

c.  This  list  should  be  complete.  In  compiling  Table 
1.2,  most  project  managers  stated  that  there  are  no  other 
factors  to  evaluate  requested  changes. 

8.  As  the  project  passes  through  the  various  stages  of  the 
programming,  design,  and  construction  process  consider 
about  how  your  evaluation  factors  will  change  during  these 
different  stages. 

a.  Most  experienced  project  managers  would  state  that 
the  project  proceeding  through  design  and  construction 
increases  the  difficulty  to  incorporate  a  requested  change. 
A  typical  project  manager's  predispositions  toward  a 
request  would  not  change  in  different  project  phases.  The 
external  operating  environment  makes  it  increasing 
difficult  to  incorporate  the  change. 

b.  Consider  incorporating  some  flexibility  in  the 
conceptual  design  phase,  if  you  know  during  later  project 
phases  you  will  receive  requested  changes. 

9.  If  you  need  any  further  information,  considering  asking 
your  favorite  MAJCOM  or  AFRCE  for  assistance.  After  all, 
their  responses  were  used  in  the  preparation  of  this 
document. 
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Table  1.2  (Continued) 
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This  research  examines  the  evaluation  process  of  Air  Force  design  and 
construction  project  managers  on  user  requested  changes  to  facility 
construction  projects.  Project  managers  who  incorporate  user  requested 
changes  probably  enhance  the  facility  quality,  but  also  adversely  affect  the 
project  execution  (on  time  and  within  available  resources)  and  the  Air  Force 
image  before  Congress.  The  researcher  interviewed  27  experienced  project 
managers  in  3  different  organizations  on  their  decision-making  processes  to 
balance  the  tradeoffs  between  cost,  performance,  enhancing  user 
productivity,  and  schedule. 

This  research  employs  a  "reason  analysis"  methodology.  Therefore,  this 
research  develops  rather  than  tests  a  specific  hypothesis.  Frequency  counts 
and  open-ended  questions  help  show  the  most  important  criteria  in  the 
decision  making  process.  Relating  responses  of  various  questions  helped  the 
researcher  gain  insights  into  the  change  request  process  in  general. 

The  research  developed  an  information  guide  for  use  by  Air  Force 
project  managers  when  evaluating  user  change  requests.  This  guide  helps  to 
educate  project  managers  from  the  experiences  of  other  project  managers. 

Evaluating  user  change  requests  includes  the  following  three  major 
areas:  their  early  detection,  the  administrative  process,  and  the 
evaluation  factors.  Early  detection  of  user  change  requests  are  derived 
from  factors  that  caused  revisions  to  the  original  change  request.  The 
administrative  process  includes  those  procedural  items  judged  most  important 
by  the  interviewees.  The  research  divided  the  evaluation  factors  into  two 
classifications.  The  first  group  addresses  why  project  managers  act  as  they 
do  in  evaluating  the  requests.  The  second  group  Identifies  the  factor 
associated  with  either  the  facility  quality  or  project  execution.  Also,  the 
research  scores  these  evaluation  factors  according  to  their  importance  and 
difficulty  of  use,  as  perceived  by  the  project  managers. 
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